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ABSTRACT 


-V 

The  Multimode  Guidance  (MMG)  Project,  part  of 
the  Army/Navy  Area  Defense  SAM  Technology  Pro¬ 
totyping  Program,  was  established  to  conduct  a 
feasibility  demonstration  of  multimode  guidance 
concepts.  Prototype  guidance  units  for  advanced, 
long-range  missiles  are  being  built  and  tested  under 
MMG  Project  sponsorship.  The  Johns  Hopkins  Uni¬ 
versity  Applied  Physics  Laboratory  has  been  desig¬ 
nated  as  Government  Agent  for  countermeasures  for 
the  project.  In  support  of  this  effort,  a  family  of 
computer-controlled  ECM  simulators  is  being  devel¬ 
oped  for  validation  of  the  contractor’s  multimode 
guidance  prototype  designs.  The  design  of  the  low- 
frequency  ECM  simulator  is  documented  in  two 
volumes.  This  report.  Volume  B,  describes  the  soft¬ 
ware  design;  Volume  A  describes  the  hardware 
design.  The  computer-controlled  simulator  can  emu¬ 
late  up  to  six  surveillance  frequency  jammers  in  B 
through  F  bands  and  will  be  used  to  evaluate  the  per¬ 
formance  of  home-on-jam  guidance  modes  in 
multiple  jammer  environments. 
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1.  INTRODUCTION 


The  Multimode  Guidance  (MMG)  Project,  part  of 
the  Army/Navy  Area  Defense  SAM  Technology  Pro¬ 
totyping  Program,  was  established  to  conduct  a  fea¬ 
sibility  demonstration  of  multimode  guidance  con¬ 
cepts.  Prototype  guidance  units  for  advanced,  long- 
range  missiles  are  being  built  and  tested  under  MMG 
Project  sponsorship. 

The  Johns  Hopkins  University  Applied  Physics 
Laboratory  has  been  designated  as  Government 
Agent  for  countermeasures  for  this  project.  In  sup¬ 
port  of  this  effort,  a  family  of  computer-controlled 
ECM  simulators  is  being  developed  for  validation  of 
the  contractor’s  multimode  guidance  prototype 
designs. 

The  design  of  the  low-frequency  ECM  (electronic 
countermeasures)  simulator  is  documented  in  two 
volumes.  Volume  A  describes  the  hardware  design  of 
the  simulator;  Volume  B  describes  the  software  de¬ 
sign.  The  computer-controlled  simulator  can  emulate 
up  to  six  surveillance  frequency  jammers  in  B 
through  F  bands  and  will  be  used  to  evaluate  the  per¬ 
formance  of  home-on-jam  guidance  modes  in  multi¬ 
ple  jammer  environments. 

Computer  control  allows  the  simulator  to  flexibly 
combine  modulations  into  new  patterns  and  to  accu¬ 
rately  repeat  test  frequencies.  In  particular,  complex 
time-varying  techniques  may  be  created  and  repeated 
when  needed.  In  order  to  take  full  advantage  of  the 
desktop  computer  that  comprises  the  simulator  con¬ 
troller,  proper  software  is  necessary.  The  simulator 
software  may  be  considered  in  three  parts:  the  user’s 
program,  subroutine  blocks,  and  data. 


The  user’s  program  determines  the  output  that  re¬ 
sults  when  a  test  program  is  run  on  the  controller.  A 
user's  program  can  be  written  for  each  new  test 
form,  and  each  such  program  can  give  many  differ¬ 
ent  outputs.  User  programs  may  be  constructed  to 
allow  a  wide  range  of  operator  inputs. 

The  user’s  program  determines  the  simulator  out¬ 
put  through  some  well-defined  sequence  of  steps, 
i.e.,  setting  center  frequencies,  noise  spots,  pulse 
periods,  etc.  While  each  test  program  would  have  a 
unique  collection  and  order  of  such  steps,  the  steps 
them-selves  will  be  common  to  all  programs.  The 
user’s  program  carries  out  the  steps  through  a  series 
of  program  calls  to  a  common  group  of  subroutines. 
These  subroutines  are  called  subroutine  blocks  to  dis¬ 
tinguish  them  from  any  subroutines  written  by  the 
user  as  part  of  a  particular  program. 

Subroutine  blocks  handle  common  tasks,  freeing 
the  user  from  having  to  rewrite  the  necessary  instruc¬ 
tions  for  such  tasks  every  time  a  new  test  program  is 
written.  The  subroutine  blocks  can  be  used  as 
building  blocks  in  creating  a  new  test  program.  Data 
formatting  and  addressing  are  handled  by  the  sub¬ 
routine  blocks,  using  values  stored  as  data. 

Data  used  by  the  subroutine  blocks  allow  the  user 
to  specify  the  output  in  user-friendly  terms  such  as 
frequency  and  bandwidth.  The  subroutine  blocks  will 
then  use  the  stored  data  to  convert  a  user-specified 
parameter  to  the  form  needed  by  the  hardware. 
Other  data  may  be  defined  as  needed  by  the  user. 
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2.  SIMULATOR  DESIGN  PARAMETERS 


The  reader  must  have  some  understanding  of  the 
MMG  ECM  simulator  hardware  in  order  to  follow 
the  description  of  the  simulator  soitware.  This  sec¬ 
tion  will  briefly  summarize  the  simulator  hardware 
design  and  parameters.  For  a  more  detailed  discus¬ 
sion,  the  reader  should  consult  the  hardware  docu¬ 
mentation  (Ref.  1).  Appendix  A  of  this  report  con¬ 
tains  a  block  diagram  of  the  simulator  (Fig.  A-l). 

The  simulator  essentially  consists  of  three  major 
parts:  the  controller,  the  multiprogrammer,  and  the 
RF  channels.  In  addition,  there  are  arbitrary  wave¬ 
form  generators,  auxiliary  modulation  switch  matri¬ 
ces,  level  set  attenuator  drivers,  distribution  boxes, 
and  power  supplies.  All  of  the  present  low-frequency 
system  (LFS)  components  except  the  controller  are 
mounted  in  a  rack  frame. 

The  controller  is  an  HP9825S  desktop  computer, 
with  a  number  of  ROM  (read-only  memory)  options 
and  a  total  of  22,910  bytes  of  useable  memory  (the 
controller  may  be  upgraded  to  the  982 5 T  standard  or 
even  changed  to  a  different  model  such  as  the 
HP9826  without  affecting  the  software’s  basic  de¬ 
sign  logic).  The  controller  communicates  with  the 
other  simulator  devices  over  the  IEEE-488  bus.  There 
are  direct  bus  connections  between  controller  and 
multiprogrammer  and  between  controller  and  arbi¬ 
trary  waveform  generators;  the  controller  is  indi¬ 
rectly  connected  to  other  parts  of  the  simulator 
through  the  multiprogrammer. 

The  multiprogrammer  consists  of  an  HP6942 
multiprogrammer  and  an  HP6943  extender.  Any 
general  reference  in  this  report  to  the  HP6942  as  the 
multiprogrammer  may  be  understood  to  include  the 
HP6943  as  a  subservient  part.  The  multiprogrammer 
contains  a  number  of  slots  holding  digital  cards  of 
various  types,  such  as  digital  output  cards,  digital  to 
analog  cards,  etc.  The  controller  sends  data  through 
the  multiprogrammer  to  an  addressed  card  in  some 
particular  slot,  causing  those  data  to  be  passed  to 
whatever  is  connected  to  the  card.  The  path  could  be 
reversed,  with  the  data  on  a  card  being  sent  back  to 
the  controller.  This  would  particularly  apply  to  use 
of  the  digital  input  card.  In  the  present  LFS  version 
of  the  simulator,  the  data  flow  is  essentially  one  way. 


1  H.  M.  Kaye,  Multimode  Guidance  Project  Low 
Frequency  ECM  Simulator:  Hardware  Description, 
JHU/APLTG  1 335 A  (Oct  1982). 


from  the  controller  to  the  output  devices,  and  no 
input  measurements  are  made  by  the  controller. 

Of  particular  interest  are  the  tune  cards  and  the  ri 
channel  function  control  cards.  Each  tune  card  holds 
two  8-bit  words  that  specify  the  status  of  an  Rt 
channel’s  tune  frequency  D/A  converter  and  hence 
specify  the  tune  frequency.  The  tune  D/A  number 
must  be  sent  to  the  correct  half  of  the  appropriate 
card  without  affecting  the  other  half  of  the  card. 
Each  channel  function  control  card  holds  a  16-bit 
word  that  determines  the  status  of  devices  within  an 
RF  channel,  as  follows: 


Bit  15 
Bits  12-14 
Bits  9-11 
Bits  6-8 
Bits  3-5 
Bits  0-2 


:  selected  VCO, 

:  biphase  circuit  control, 

:  pulse  circuit  control, 

:  fill  oscillator  attenuation, 

:  noise  generator  attenuation,  and 
:  noise  video  bandwidth. 


Other  multiprogrammer  cards  control  the  level  set 
attenuators  and  the  auxiliary  modulation  switch 
matrices,  handle  D/A  conversion  for  auxiliary  am  or 
fm,  provide  a  pulse  signal  source  from  the  timer/ 
pacer  card,  and  handle  memory  data  (in  the  present 
LFS  version,  the  memory  cards  are  not  used).  For 
example,  the  digital  output  card  in  slot  1 1  determines 
if  the  FM  auxiliary  modulation  matrix  is  off  (latched) 
or  on,  and  if  on,  what  rf  channel  and  what  source 
are  connected  during  the  on  state.  Table  1  lists  the 
multiprogrammer  cards  and  their  purposes. 

The  six  rf  channels  generate  the  actual  frequency 
outputs.  Each  channel  has  the  same  functional  lay¬ 
out.  There  are  two  VCOs  in  each  channel,  one  of 
which  will  be  active  (connected  to  the  rest  of  the 
channel  circuitry)  at  any  time.  The  tune  center  is  de¬ 
termined  by  the  voltage  from  the  tune  D/A.  This 
voltage  into  the  VCO  may  be  modulated  by  the  fill 
oscillator,  noise  generator,  and  auxiliary  FM.  The 
VCO  output  may  be  successively  modulated  by  linear 
am,  biphase,  and  pulse  circuits.  Level  set  attenuators 
set  the  output  power  amplitude  reference  level.  There 
is  a  coupler  to  allow  the  RF  channel  output  to  be 
monitored  from  the  front  panel  of  the  rack. 

There  are  two  types  of  RF  channels  in  the  present 
LFS  version  of  the  simulator,  with  a  third  planned. 
Type  1  covers  the  B  and  C  frequency  bands.  Type  11 
covers  the  D,  E,  and  F  bands.  Table  2  summarizes 
the  major  simulator  parameters.  Type  111,  when 
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Table  1  -  Multiprogrammer  card  slots.  Table  2  -  Major  simulator  parameters. 

Slot  No.  Card  Type  Card  Purpose  Parameter  Specification 


0  Digital  memory  1st  part  of  memory  pair 
1  Digital  memory  2nd  part  of  memory  pair 


2 

Digital  output 

Tune,  RF  channels  1, 2 

3 

Digital  output 

Tune,  RF  channels  1 , 2 

4 

Digital  output 

Tune,  RF  channels  1, 2 

5 

Digital  output 

Function  control,  RF  #1 

6 

Digital  output 

Function  control,  RF  #2 

7 

Digital  output 

Function  control,  RF  #3 

8 

Digital  output 

Function  control,  RF  #4 

9 

Digital  output 

Function  control,  RF  #5 

10 

Digital  output 

Function  control,  RF  #6 

11 

Digital  output 

Level  set  control 

12 

Digital  output 

AM  &  FM  auxiliary  switch 
matrices 

13 

Timer/pacer 

Pulse  source  (50%  square 
wave) 

14 

Counter 

Input  pulse  counting 

15 

Extender 

Connect  6942, 6943 

100 

D/A 

AM,  RF#1 

101 

D/A 

AM,  RF  #2 

102 

D/A 

AM,  RF  #3 

103 

D/A 

AM,  RF  #4 

104 

D/A 

AM,  RF#5 

105 

D/A 

AM,  RF  #6 

106 

D/A 

FM 

107 

Digital  input 

Input  measurements 

Note:  Slots  0-1 5  are  in  the  HP6942  multiprogramer; 
slots  100-107  are  in  the  HP6943  extender. 

available,  will  cover  the  G,  H,  and  I  bands  and  a 
small  part  of  the  J  band. 

There  are  two  WI75  arbitrary  wave  form  genera- 

tors  available  as  part  of  the  simulator.  These  devices 
may  be  used  to  generate  almost  any  voltage  wave¬ 
form  that  can  be  defined  as  a  function  of  time.  One 


Frequency  coverage 
Type  I,  VCO  A  250-500  MHz 

VCO  B  500  MHz;  I  GHz 
Type  II,  VCO  A  1-2  C.Hz 
VCO  B  2-4  GHz 

Frequency  accuracy  8  bit  (256  steps)  over  VCO  range 
(accuracy  within  8  MHz;  cali¬ 
bration  dependent) 

RF  power 

Type  I  +  20  dBm,  maximum 

Type  II  +  17  dBm,  maximum 

Dynamicrange  81  dB ( 1  dU  steps) 

Modulation  types 
FM 

Noise  Gaussian  or  non-Gaussian,  video 

bandwidths  of  1,  10, 

100  kHz;  1,5  MHz 
Fill  100  kHz  square  wave 

Auxiliary  Sources:  arbitrary  waveform  gen¬ 

erator,  D/A  card,  or  external. 

AM  >55  dB  maximum  range,  DC  to 

50  kHz  rates 

Sources:  arbitrary  waveform  gen¬ 
erator,  D/ A  card,  or  external 

Biphase  5,  10,  or  20  MHz  comb; 

10,  20,  or  40  MHz  psuedoran- 
dom  noise 

Pulse  PRF  500  kHz,  maximum 

Sources:  10,  100  Hz  (50%  square 
wave),  timer/pacer  card  (50% 
square  wave),  either  W175, 
external 

may  be  used  for  FM  or  pulse,  the  other  for  am  or 
pulse.  The  waveform  generators  are  directly  set  by 
the  controller;  their  outputs  must  be  switched  in 
through  the  multiprogrammer  to  affect  the  RF 
channel  outputs. 

The  simulator  output  devices  may  be  set  indepen¬ 
dently,  and  outputs  are  formed  by  combining  the  ef¬ 
fects  of  several  devices.  Unique  test  patterns  can  be 
generated  by  having  the  controller  change  device 
settings  according  to  some  desired  scheme.  Any  test 
program  would  essentially  be  concerned  with  deter¬ 
mining  the  hardware  status  of  ihe  simulator  at  any 
time  during  that  lest. 
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3.  SOFTWARE  FUNCTIONAL  DESCRIPTION 


Basic  Organization 

The  controller  is  the  key  to  the  simulator’s  ability 
to  output  complex  test  waveforms.  For  time-depen¬ 
dent  modulations,  the  controller  can  accurately  con¬ 
trol  the  sequence  and  timing  of  program  steps. 

Throughout  this  report,  the  user  is  undersutod  to 
be  anyone  who  uses  the  information  in  the  report  to 
write  a  test  program.  The  operator  is  anyone  who 
runs  a  test  program.  The  user  and  operator  need  not 
be  the  same  person. 

A  user’s  test  program  is  essentially  concerned  with 
controlling  the  ECM  simulator  status  during  the  test. 
In  doing  so,  the  test  program  specifies  the  test  format 
(i.e.,  the  simulator  status  at  each  step).  Each  test  for¬ 
mat  requires  its  own  unique  test  program,  which 
must  be  provided  by  the  user. 

The  user’s  program  may  directly  specify  the  pa¬ 
rameter  values  used  in  a  test  or  it  may  allow  an  opera¬ 
tor  to  select  them.  In  the  former  case,  the  controller 
can  prompt  an  operator  to  enter  the  test’s  parameter 
values  and  then  verify  that  they  are  legal.  The  con¬ 
troller  can  also  provide  the  operator  with  a  list  or 
menu  of  parameters,  the  operator  entering  values  for 
only  those  that  differ  from  a  set  of  standard  values. 
When  an  illegal  entry  is  made,  the  controller  can  in¬ 
form  the  operator  and  reprompt  for  a  new  value. 
Also,  the  user’s  program  can  record  the  parameter 
values  for  test  documentation. 

The  controller’s  software  has  been  organized  so 
that  the  user  may  specify  the  simulator’s  status  using 
output-oriented  parameters  such  as  frequency  or 
bandwidth,  instead  of  specific  hardware  parameters 
such  as  D/A  number  or  attenuator  setting.  A  test 
program  will  use  a  number  of  subroutines  common 
to  all  test  programs.  These  subroutines  are  called 
subroutine  blocks  in  order  to  distinguish  them  from 
other  subroutines  prepared  by  a  user  for  a  specific 
test  program.  The  subroutine  blocks  will  handle  the 
details  of  a  particular  step  in  a  test  format,  freeing 
the  user  to  concentrate  on  the  test  format  itself.  Sub¬ 
routine  blocks  will  accept  output  oriented  parameters 
and  find  and  set  the  corresponding  specific  hardware 
parameters.  Data  and  device  settings  will  be  properly 
addressed  using  the  subroutine  blocks,  without 
requiring  the  user  to  have  a  rigorous  understanding 
of  the  controller’s  internal  setup. 

The  subroutine  blocks  are  used  to  build  up  a  test 
format  by  setting  devices  and  running  sequences 


through  the  controller.  The  lest  format  is  determined 
by  the  user  who  is  responsible  for  writing  a  program 
that  organizes  and  uses  the  subroutine  blocks  as 
needed.  If  required,  the  user’s  program  may  set  out¬ 
put  devices  without  using  the  subroutine  blocks  but 
should  not  normally  need  to  do  so. 

Subroutine  blocks  are  independent  in  that  the  data 
set  by  one  subroutine  will  not  affect  data  set  by 
others,  unless  several  subroutines  affect  the  same  de¬ 
vice  or  when  one  subroutine  block  calls  upon  others. 
For  example,  the  pulse  circuit  switch  of  a  given  rf 
channel  can  be  directly  set  without  affecting  any 
other  settings,  while  the  pulse  circuit  switch  will  auto¬ 
matically  be  reset  properly  when  a  subroutine  block 
is  used  to  set  up  either  of  the  arbitrary  waveform  gen¬ 
erators  or  the  timer/pacer  card  as  a  pulse  source  for 
that  RF  channel.  Independent  subroutine  blocks 
make  it  easier  for  a  user  to  prepare  complex  test  mod¬ 
ulations  in  a  simple  building-block  fashion. 

The  subroutine  blocks  require  conversion  data  in 
order  to  get  the  hardware  settings  that  correspond  to 
the  output-oriented  parameters  specified  by  the  user. 
Such  data  are  held  in  well-defined  tables;  examples 
are  VCO  tuning  curves,  noise  spot  attenuation  tables, 
arbitrary  waveform  generator  voltage  curves,  etc. 
Other  data  may  be  defined  by  the  user  for  a  specific 
test;  such  data  would  typically  consist  of  parameter 
values  to  be  passed  on  to  the  subroutine  blocks. 

The  basic  organization  of  any  test  program  will  be 
a  hierarchical  allocation  of  the  available  controller 
memory  among  the  user’s  program,  the  subroutine 
blocks,  and  the  data.  The  user’s  program  uses  the 
subroutine  blocks  to  specify  certain  tasks,  and  the 
subroutine  blocks  use  the  data  in  carrying  out  those 
tasks.  The  organization  of  the  user’s  program  de¬ 
pends  on  the  test  involved,  as  indicated  below. 


Basic  Programming  Steps 

Test  Definition 

As  the  first  step  in  any  test  program,  the  user  must 
be  able  to  define  the  purpose  of  the  test.  The  purpose 
of  the  test  should  in  turn  suggest  the  general  sort  of 
modulation  pattern  to  use.  Test  definition  is  closely 
related  to  form  definition  (below),  and,  ir  practice. 
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the  two  steps  will  often  be  carried  out  simultan¬ 
eously.  The  distinction  is  that  test  definition  treats 
the  entire  simulator  system  as  a  black  box  out  of 
which  the  test  designer  wants  some  particular  modu¬ 
lation  pattern,  while  form  definition  is  used  to  set  up 
the  user’s  program  in  the  controller.  Test  definition 
may  be  carried  out  by  a  test  designer  who  then  directs 
the  user  to  program  the  controller  for  that  test;  the 
test  designer  need  not  be  directly  concerned  with  the 
actual  program. 


Form  Definition 

With  a  specific  test  definition  as  the  goal,  the  user 
must  form  a  program  to  carry  out  the  test.  This  will 
involve  determining  at  every  part  of  a  test  the  output 
device  changes  to  be  set  and  the  parameter  values  of 
those  changes.  The  user’s  program  handles  tasks  in 
three  areas:  initialization,  parameter  determination, 
and  output  setting.  Initialization  would  be  a  fairly 
standard  procedure  followed  after  power  is  turned  on 
and  a  test  started.  Most  of  the  user’s  work  load  in 
preparing  a  test  involves  parameter  determination, 
with  output  setting  being  handled  through  the  sub¬ 
routine  blocks. 

In  order  to  determine  parameter  values,  one  must 
know  what  parameters  are  needed,  which  amounts  to 
knowing  what  devices  should  be  set.  The  user  should 
find  it  helpful  to  consider  the  test  as  a  sequence  of  in¬ 
tervals,  where  each  interval  change  is  marked  by 
some  notable  change  in  the  simulator  status. 

During  each  interval,  the  user’s  program  needs  to 
explicitly  handle  only  those  devices  whose  status 
changes  from  their  status  in  the  previous  interval. 
Other  devices  would  remain  as  they  were  previously 
set.  A  number  of  changes  closely  timed  can  be  con¬ 
sidered  as  one  interval.  How  close  such  timing  must 
be  is  up  to  the  user;  the  point  of  an  interval  structure 
is  to  make  it  easier  to  translate  a  test  design  to  actual 
programming. 

In  setting  up  intervals,  the  user  should  be  aware  of 
the  distinction  between  a  set  type  and  a  run  type  out¬ 
put.  A  set  type  subroutine  (which  should  be  a  subrou¬ 
tine  block)  will  use  the  controller  to  set  some  other 
simulator  device,  with  the  resulting  state  remaining  in 
force  until  the  device  involved  is  explicitly  changed. 
A  run  type  subroutine  (which  may  be  a  subroutine 
block,  or  a  modified  one,  or  a  new  one  written  by  the 
user)  will  use  the  controller  to  run  a  modulation 
pattern.  The  pattern  may  involve  rapid,  timed  device 
changes  that  would  tie  up  the  controller.  To  illustrate 
this,  consider  an  example  of  a  hopping  noise  spot. 


The  noise  spot,  power  level,  carrier  signals,  and  the 
like  can  be  handled  by  set  type  subroutines.  The  hop 
can  be  handled  by  having  the  controller  rapidly 
change  the  center  frequency  of  the  VCO  used 
through  a  run  type  subroutine. 

The  distinction  between  set  and  run  types  is  impor¬ 
tant  in  setting  up  a  sequence  of  intervals.  A  run  type 
output  ties  up  the  controller  so  that  no  other  tasks 
can  be  carried  out  while  such  an  operation  is  running. 
When  the  controller  stops  running  such  an  operation 
and  moves  on  to  its  next  task,  the  run  type  output 
will  end.  The  beginning  and  end  of  run  type  outputs 
provide  suitable  interval  divisions.  No  run  type  out¬ 
put  from  one  interval  will  continue  into  a  following 
interval.  When  several  set  type  outputs  and  a  run 
type  are  used  in  an  interval,  the  set  type  subroutines 
are  obviously  called  first. 

Timing  between  intervals  (and  within  the  steps  of  a 
run  type  output)  is  provided  by  the  controller. 
Timing  control  would  typically  use  the  wait  instruc¬ 
tion,  making  allowances  for  the  time  it  takes  the  con¬ 
troller  to  carry  out  its  operations.  Timing  control 
may  also  involve  the  multiprogrammer’s  real-time 
clock.  The  user  may  allow  an  operator  to  control  in¬ 
terval  timing  through  the  controller’s  keyboard. 

Appendix  B  contains  more  information  on  the 
basic  programming  steps. 


Parameter  Determination 

Parameter  values  may  be  found  in  a  number  of 
ways.  The  ways  can  be  distinguished  according  to 
whether  literal  numbers  or  variables  are  used  in  the 
actual  subroutine  calls  and  preliminary  calculations; 
in  the  case  of  the  latter,  there  are  three  ways  of 
getting  the  value  of  the  variable  contents.  Any  com¬ 
bination  of  ways  may  be  used  in  a  program.  The 
ways  are: 

1 .  Direct  number 

2.  Variable 

a.  Program 

b.  Data  file 

c.  Operator  entry 

A  direct  number  is  easy  to  use  but  tedious  to 
change.  Variables  (including  expressions)  make  it 
easier  to  run  the  same  test  form  repeatedly  with  dif¬ 
ferent  values  on  each  run.  Variables  may  be  assigned 
direct  numbers  within  a  program.  This  is  similar  to 
use  of  direct  numbers  since  it  requires  program  modi- 
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fieacions  in  order  lo  change  the  values,  but  by  col¬ 
lecting  all  assignments  in  one  part  of  the  program  it 
becomes  easier  to  make  such  changes  than  it'  numbers 
were  scattered  throughout  the  program.  Variables 
may  also  be  assigned  through  the  use  of  some  prede¬ 
fined  and  taped  data  array  prepared  by  the  user. 
Such  arrays  allow  a  test’s  parameter  values  to  be  eas¬ 
ily  changed  by  changing  the  file  contents  loaded  from 
tape. 

More  particularly,  the  user  may  set  up  a  program 
to  allow  an  operator  to  specify  parameter  values  at 
the  time  of  the  test  run.  Operator  inputs  can  be 
checked  by  the  program.  Several  subroutine  blocks 
also  make  it  easier  to  handle  operator  inputs.  Default 
values  should  be  provided  in  case  the  operator  does 
not  wish  to  change  a  typical  value;  this  will  reduce  the 
operator’s  workload  and  save  testing  time.  The  con¬ 
troller  can  prompt  the  operator  with  type  and  range 
information  for  each  input. 

Appendix  C  contains  more  information  on  param¬ 
eter  determination  and  passing. 


User  Subroutines 

User  Defined 

The  user  will  find  it  advantageous  to  make  heavy 
use  of  subroutines  when  preparing  a  new,  compli¬ 
cated  program.  Use  of  subroutines  written  by  the 
user  can  make  it  easier  to  follow  the  structure  of  a 
program  and  to  modify  that  program  for  later  use  in 
a  differen'  test  form.  Also,  by  using  subroutines 
written  according  to  a  few  general  rules  (chiefly  in¬ 
volving  internal  variables  used  within  the  sub¬ 
routine),  the  user  can  build  up  a  library  of  new  sub¬ 
routines  to  join  with  the  subroutine  blocks  as  a 
source  of  prewritten  program  building  blocks.  This 
should  be  particularly  useful  when  the  user  prepares 
any  new  run  type  output  subroutines. 

Label  names  can  be  used  to  positively  identify  a 
subroutine,  including  its  purpose.  The  only  restric¬ 
tions  on  the  labels  available  to  the  user  are  that  the 
label  must  fit  on  one  program  line  and  must  be 
unique  (see  Table  3  for  a  list  of  labels  already  in  use 
by  the  subroutine  blocks).  Labels  may  also  be  used 
elsewhere  in  a  program  to  set  off  the  structure  and  to 
handle  program  branching. 

The  actual  purpose  and  form  of  user-defined  sub¬ 
routines  are  up  to  the  user  and  will  depend  on  the  test 
definition.  Appendix  D  contains  more  information 
on  user-defined  subroutines. 


Table  3  - 

Subroutine  block  labels. 

7 

initial 

fval# 

stepinod 

fset 

'stepval 

fnoise 

•slepwt 

fnout 

OWnSWp 

pulse 

swpl  75 

biph 

AM  175 

auxmod 

DC  175 

AMaux 

T/P 

ampset 

special 

AMown 

’valspec 

'  AMval 

err  stp 

setVCO 

shutoff 

enter 

inRIid 

loadYS 

loadXS 

loadWS 

*  User-provided  nextval  subroutine  (see  Appendix  13). 

Predefined 

The  user  may  be  required  to  write  subroutines  to 
carry  out  a  predefined  task  in  order  to  use  certain 
subroutine  blocks  (see  Table  4).  The  subroutine 
blocks  in  the  lefthand  column  of  Table  4  are  run  type 
subroutines  that  find  a  data  value  by  calling  on  other 
subroutines,  format  the  data,  and  send  it  to  the 
proper  address.  The  subroutines  in  the  righthand  col¬ 
umn  of  Table  4  provide  the  next  value  to  be  sent  out 
in  sequence  by  the  subroutines  that  call  them.  For 
convenience,  the  subroutines  that  return  the  data  are 
called  nextval  subroutines. 

Nextval  subroutines  mu  '  be  provided  by  the  user 
and  must  return  the  necessary  data  through  a  speci¬ 
fied  variable.  The  actual  output  of  a  calling  subrou¬ 
tine  is  largely  determined  by  the  nextval.  By  changing 
the  nextval,  the  user  can  easily  change  the  output, 
without  having  to  rewrite  all  the  necessary  addressing 
or  formatting  instructions  handled  by  the  calling  sub¬ 
routines.  A  nextval  may  take  any  number  of  forms, 
from  complicated  calculations  to  simple  lookup  of  a 
table  prepared  in  advance. 

Appendix  D  contains  more  information  on  nextval 
subroutines. 


Data 

The  subroutine  blocks  primarily  use  local  dynam¬ 
ically  allocated  p-numbers  as  internal  variables,  with 
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Table  4  -  Nextval  subroutines. 


Subroutine  Block  Nextval  Subroutine/ Returns' 


AMown 


AMval/dB  of  attenuation 


stepmod  stepval/  D/  A  code  number 

stepwt/dwell  at  value  (ms) 

special  valspec/double  tune  word 

single  tune  word 

3  channel  function  control  words 


As  a  rule  of  thumb,  the  user  should  not  assign  new 
values  to  any  of  the  variables  just  listed.  They  may  be 
read  at  any  time.  All  other  global  variables  (and  flags 
0-12)  are  available  to  the  user.  Flag  14  is  set  and  unset 
by  most  of  the  subroutine  blocks;  if  the  user  wants 
flag  14  set  in  the  user’s  program,  the  flag  must  be 
reset  after  calling  a  subroutine  block  that  affects  the 
flag  or  the  blocks  must  be  modified. 

Appendix  E  contains  more  information  on  data 
and  variables. 


'  See  Appendix  D  for  return  limits. 

a  few  global  variables  (those  visible  to  the  user’s  pro¬ 
gram)  for  loop  indices  and  nextval  returns.  Most 
global  variables  used  by  the  subroutine  blocks  hold 
data  tables  used  when  converting  output-oriented  pa¬ 
rameters  to  hardware-oriented  ones  (see  Table  5). 

The  data  tables  must  be  dimensioned  and  loaded  at 
the  start  of  a  test.  The  noise,  fill,  and  W175  (FM) 
tables  may  need  to  be  updated  from  tape  storage 
when  the  active  VCO  in  an  rf  channel  changes  or 
when  the  noise  video  bandwidth  changes.  Subroutine 
blocks  (“load-$”)  will  handle  such  updating. 

The  subroutine  blocks  use  the  following  global 
variables  and  flags: 


simple 

:  U  through  Z 

array 

:  X,  Z 

string 

:  U  through  Z 

flag 

:  14 

Error  Handling 

The  subroutine  blocks  will  carry  out  a  number  of 
simple  checks  on  the  parameter  values  passed  to 
them.  The  checks  are  chiefly  to  ensure  that  a  particu¬ 
lar  subroutine  block’s  parameters  are  legal  and  with¬ 
in  range.  Checks  in  one  subroutine  block  are  inde¬ 
pendent  of  checks  in  other  blocks.  If  an  error  is 
found,  the  subroutine  blocks  have  no  general  provi¬ 
sion  for  prompting  an  operator  to  correct  an  error, 
and  use  of  defaults  could  lead  the  user  and  operator 
into  misinterpreting  the  status  of  the  simulator. 
When  an  error  is  found,  the  subroutine  blocks  will 
therefore  set  a  coded  number  in  the  variable  Z  to  in¬ 
dicate  the  cause  of  the  error  and  then  branch  to  a 
routine  that  reports  the  error,  shuts  off  the  simulator 
output,  and  stops  the  program.  This  requires  a  con- 


T able  5  -  Required  dimensioned  variables. 

Label  Purpose  Where! How  Loaded * * 


Z$[  12,54]  Tune  frequency  data 


File  2 


X$  [6, 1 20  ]  Noise  generator  data 


File  6,  ‘MoadXS” 


Y$  [6,1 20  ]  Fill  oscillator  data 


File  5,  “loadYS” 


W$[6,120]  WI75-FM  data 


File  4,  “loadWS” 


V$  ( 120 1  Tape-controller  data  transfers* 


U$(36]  Calibration  identification,  W175  File 9 1 

outputs,  operator  input  sub¬ 
routines* 


X  [  1 4  ]  Long-term  constants  File  3 

Z[22]  Card  words  — 

*  May  be  used  by  user’s  program  if  care  is  taken  to  avoid  overwriic 
conflicts. 


••Tape  files  are  all  on  track  1. 
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scious  effort  by  an  operator  to  restart  the  lest,  which 
helps  ensure  that  the  operator  will  be  aware  of  the 
error  that  must  be  fixed. 

The  user  can  avoid  such  controlled  crashes  by 
checking  parameter  values  before  calling  the  sub¬ 
routine.  It  would  then  be  possible  for  the  user  to  de¬ 
fine  how  to  recover  from  a  faulty  parameter.  Nota¬ 
bly,  the  user’s  program  can  check  operator  entries, 
and  if  an  error  is  found  the  program  can  reprompt 
the  operator. 

Appendix  F  contains  more  information  on  error 
handling. 

Ancillary  Devices 

Tape 

The  HP9825  controller  has  a  magnetic  tape  cart¬ 
ridge  that  will  store  programs  and  data  on  two 
tracks.  About  20%  of  the  track  1  is  reserved  in  a  defi¬ 
nite  format  to  hold  data  for  the  subroutine  blocks 
(see  Table  6);  track  0  and  the  rest  of  track  1  are  avail¬ 
able  to  the  user.  It  is  recommended  that  file  0  of  track 
0  on  program  tapes  be  used  to  store  an  index  and 
guide  to  the  rest  of  the  tape  contents. 

Appendix  G  contains  more  information  on  the  use 
of  the  tape. 

Tables  -  Tape  track  1  reservations. 

Files  I  to  91  on  track  1  are  reserved  for  the  subroutine 

block  data,  as  follows: 

File  No.  Use 

1  Transfer  program 

2  Z$  (tune  data) 

3  Xl’Kconsiants  table) 

4  W$  (initial  load,  W 1 75  data) 

5  Y$  (initial  load,  fill  oscillator  data) 

6  X$  (initial  load,  noise  generator  data) 

7-18  Fill  oscillator  data 

1 9-90  Noise  generator  data 

91  Calibration  identification 


W'  175  Arbitrary  W  aveform  Generator 

The  simulator  has  two  WI75  programmable  aibi 
trary  waveform  generators.  Th  may  be  pro¬ 
grammed  tor  any  voltage  waveform  that  can  be  de¬ 
fined  as  a  function  of  time  A  number  of  standard 
waveforms  are  available  in  ROM;  arbitrary  ones  may 
be  stored  in  PROM  (programmable  read-only  mem¬ 
ory)  or  RAM  (random  access  memory).  Output  rates 
for  a  full  WPS  waveform  block  may  range  up  to 
19.5  kHr  (higher  if  a  partial  block  is  used);  the  out¬ 
put  modulation  rate  may  be  different  from  the  W175 
block  rate,  depending  on  the  voltage  amplitude. 

It  is  the  responsibility  of  the  user  to  avoid  alloca¬ 
tion  conflicts.  One  W175  may  be  used  for  KM  or  pulse 
and  the  other  for  AM  or  pulse;  the  user  must  avoid 
using  either  W175  for  both  purposes  simultaneously  . 
The  waveforms  and  voltages  for  the  two  applications 
are  not  compatible.  Normally  this  is  not  a  problem 
and  can  be  handled  implicitly  in  the  way  a  program 
runs.  Explicit  status  tracking  may  be  necessary  if  an 
operator  controls  the  sequence  of  test  intervals. 

Appendix  H  contains  more  information  on  the  use 
of  the  W 175  waveform  generators. 

User  Documentation 

The  user  should  document  any  new  test  program 
that  is  significantly  different  from  existing  programs, 
is  likely  to  be  used  by  others,  or  is  considered  a  major 
test  program.  Programs  can  be  partly  self-docu¬ 
menting  through  good  use  of  labels.  File  0  on  track  0 
of  a  program  tape  can  contain  a  brief  guide  to  the  test 
program.  The  controller’s  internal  printer  may  be 
used  to  document  test  parameter  values. 

Written  documentation  should  identify  any  new 
subroutines  that  may  be  useful  in  other  programs, 
identify  data  files  and  requirements,  and  identify  the 
tape  files  that  hold  parts  of  the  program.  Also,  if  op¬ 
erator  inputs  are  accepted,  the  user’s  documentation 
should  include  an  operator’s  guide  detailing  the 
available  options  at  each  input.  A  program  listing 
should  always  be  taken  and  given  for  hard-copy 
reference. 

Appendix  I  contains  more  information  on  user 
documentation. 

Miscellanous  Information 

There  are  a  number  of  small  corrections  and  modi¬ 
fications  that  could  be  made  in  the  subroutine 
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blocks.  These  are  detailed  in  Appendix  K.  None 
would  significantly  change  the  subroutine  block 
logic. 

Appendix  L  contains  a  program  checklist. 

Appendix  M  contains  short  miscellaneous  infor¬ 
mation  that  the  reader  may  find  useful. 

Appendix  N  contains  one-line  descriptions  of  the 
subroutine  blocks,  with  more  detailed  descriptions  in 
Appendixes  O  and  P. 

A  number  of  programs  have  been  prepared  using 
the  subroutine  blocks;  these  will  be  described  separ¬ 
ately.  In  particular,  a  demonstration  program  has 
been  prepared  that  will  allow  an  operator  to  arbi¬ 
trarily  set  up  simple  set  type  outputs  in  any  order  on 
any  rf  channels.  Other  programs  will  handle  data 
calibration  and  hopping  noise  spots.  It  is  planned  to 


develop  a  library  of  test  programs  and  program  ele¬ 
ments  (such  as  subroutines)  so  that  the  user  would 
find  an  existing  program  to  handle  a  test. 
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APPENDIX  B 


BASIC  PROGRAMMING  STEPS 


The  MMG  ECM  simulator  allows  a  test  designer  to 
create  ECM  outputs  by  flexibly  combining  the  out¬ 
puts  of  various  devices  in  the  rf  channels  and  the  ar¬ 
bitrary  waveform  or  external  generators.  The  simu¬ 
lator  controller  can  run  complex  time-varying  modu¬ 
lation  patterns  by  timed  changes  of  device  settings. 
Within  the  limits  set  by  the  actual  and  available  simu¬ 
lator  hardware  and  by  the  speed  and  memory  size  of 
the  controller,  test  designers  can  write  programs  for 
any  number  of  tests.  This  appendix  outlines  some 
basic  steps  common  to  any  program.  The  section  is 
necessarily  general  since  there  can  be  many  ways  of 
getting  the  same  output. 

A  test  program  can  be  considered  conceptually  in 
two  parts:  the  subroutine  blocks  and  the  user’s  pro¬ 
gram.  The  subroutine  blocks  can  be  used  on  a  black 
box  level  to  handle  the  details  of  a  test,  such  as 
finding  the  code  numbers,  switch  settings,  addresses, 
etc.  that  will  give  the  desired  output.  The  user’s  pro¬ 
gram  basically  handles  everything  else  besides  the 
subroutine  blocks,  such  as  specifying  the  desired  out¬ 
put  in  terms  of  frequencies,  power  levels,  band- 
widths,  etc.  The  user’s  program  determines  the  form 
and  parameters  of  a  test. 

The  user’s  program  in  turn  can  be  considered  in 
thiee  broad  areas:  initialization,  parameter  determin¬ 
ation,  and  output  setting.  Initialization  consists  of 
setting  up  controller  data  space,  loading  necessary 
files  and  subroutine  block  data,  and  initializing  the 
hardware  status.  It  is  the  most  consistent  in  form 
from  one  test  program  to  another  of  the  three  areas. 
Parameter  determination  can  involve  fixed  literal 
numbers,  data  loaded  from  tape,  programmed  algo¬ 
rithms,  or  operator  entries  at  the  time  of  the  test,  and 
may  involve  a  fixed  output  form  or  one  determined 
by  an  operator  at  the  time  the  test  is  run.  It  may  be 
carried  out  as  one  stage  of  a  test  setup  or  it  may  be  a 
repeated  part  of  a  cycle.  Most  of  the  user  pro¬ 
grammer’s  workload  will  involve  parameter  deter¬ 
mination  (especially  for  complex  test  forms).  Output 
setting  involves  the  actual  setting  of  simulator  devices 
and  running  of  modulation  patterns,  primarily 
carried  out  when  the  user’s  program  calls  the  sub¬ 
routine  blocks.  Each  area  is  briefly  described  below. 
The  reader  should  be  aware  that  there  is  some  over¬ 
lap  of  these  areas,  such  as  in  the  case  of  a  subroutine 


block  that  determines  each  output  value  in  a 
sequence  as  that  value  is  needed  (e.g.,  "stepmod”). 
Parameter  determination  and  output  setting 
implicitly  assume  that  the  user  has  determined  the 
output  form  (see  below). 

Initialization  sets  up  the  simulator  to  run  a  test. 
This  requires  that  (a)  data  space  be  dimensioned  in 
the  controller’s  memory  and  data  loaded  from  tape 
storage;  (b)  any  separately  taped  program  segements 
be  added  to  memory  as  needed;  (c)  the  simulator 
hardware  be  put  in  a  known  slate;  and  (d)  the  state  be 
suitable  for  the  subroutine  block  operation.  The  pre¬ 
ferred  sequence  of  initialization  instructions,  with 
optional  steps  in  parentheses,  is: 

Dimension  data, 

(load  subroutine  blocks), 

Call  “initial”  subroutine, 

(enable  “shut  off”  error  branch), 

Load  subroutine  data, 

(load  program  data), 

(load  program  segment). 


The  data  that  must  be  dimensioned  include  those 
required  by  the  subroutine  blocks  (see  Appendix  E), 
plus  ?ny  arrays  or  strings  required  by  the  user’s  pro¬ 
gram.  Simple  variables  need  be  dimensioned  only  if 
the  user  intends  to  record  all  data.  If  the  subroutine 
blocks  are  not  an  integral  part  of  the  program  file 
(i.e.,  if  they  are  not  stored  as  part  of  the  same  tape 
file  as  the  program  doing  the  initialization),  they 
should  be  loaded  with  the  load  instruction  specifying 
that  the  program  continue  at  the  call  part  of  initiali¬ 
zation  (see  Appendix  G).  The  “initial”  subroutine 
will  set  the  simulator  hardware  to  a  desired  known 
stale  and  initialize  the  array  used  to  hold  multipro- 
grammer  card  words  (see  Appendixes  E  and  J).  This 
subroutine  should  always  be  called  as  soon  as  possi¬ 
ble  in  any  program.  User  programs  should  also  en¬ 
able  the  error  branch  to  the  “shutoff  subroutine, 
which  will  control  the  program  halt  that  results  if  the 
controller  (as  opposed  to  the  subroutine  blocks)  de¬ 
tects  an  error  (such  as  division  by  zero  with  Hag  14 
unset).  This  enable  is  not  required  but  is  recom¬ 
mended. 


tvmstmM 
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After  the  call  to  “initial”,  ihe  user’s  program 
loads  the  data  needed  by  the  subroutine  blocks  (see 
Appendix  E)  and  may  load  any  prerecorded  data 
needed  by  the  user’s  program.  If  the  user’s  program 
has  been  written  in  the  form  of  several  separately 
taped  parts,  then  the  initialization  part  of  the  pro¬ 
gram  should  load  the  first  (noninitialization)  part  if  it 
was  not  taped  as  part  of  the  initialization.  A  useful 
instruction  that  the  user  can  insert  after  the  last  tape 
access  instruction  is  to  rewind  the  tape  because  this 
will  reduce  tape  stress  and  wear  if  the  operator 
should  remove  the  tape  without  using  the  rewind  key 
(see  Appendix  G).  Where  the  last  lape-access  instruc¬ 
tion  is  depends  on  what  tape  uses  there  are  in  the 
user’s  program. 

Parameter  determination  and  output  setting  will 
depend  strongly  on  the  user’s  program.  From  an 
output  point  of  view,  the  user’s  program  is  tasked 
with  building  up  the  form  of  the  output  modulation; 
parameter  determination  and  output  settings  are  the 
means  to  that  end.  Determining  a  test’s  form  can  de¬ 
termine  fairly  well  the  output  setting  instructions, 
and  the  parameter  determination  method  can  be  any¬ 
thing  that  will  get  the  necessary  data  without  con¬ 
flicting  with  the  output  form  (this  amounts  to  re¬ 
stricting  operator  entries  during  a  timed  sequence). 

Building  up  a  lest  form  requires  the  user  to  concep¬ 
tually  break  up  the  overall  output  pattern  into  a 
number  of  time  intervals.  Each  interval  corresponds 
to  a  change  in  the  simulator  status.  The  output  pat¬ 
tern  Juring  each  interval  becomes  that  interval’s 
modulation  form,  and  the  overall  output  modulation 
is  a  sequence  of  modulation  forms.  Commonly,  there 
will  be  one  interval  in  which  the  simulator  is  brought 
up  from  initialization  to  some  desired  output  slate  in 
which  all  modulations  (including  those  run  through 
the  controller)  will  continue  until  the  operator  takes 
some  action  to  change  the  status  (such  as  turning  off 
the  power).  This  sort  of  interval,  which  remains  until 
an  outs>de  event  interferes,  can  be  termed  a  stable 
form  and  the  resulting  test  a  stable  test.  Its  counter¬ 
part  arises  when  the  simulator  is  brought  up  to  one 
output  state  for  a  time  and  then  is  moved  by  the 
user’s  program  'o  a  different  state;  each  interval  can 
be  termed  a  time-varying  form  and  the  resulting  test  a 
time-varying  test. 

The  concept  of  an  interval  may  be  extended  to 
cover  other  arrangements  in  which  the  program  per¬ 
forms  a  series  of  related  operations,  even  when  the 
program  itself  does  not  control  the  order  or  timing  of 
the  intervals.  For  example,  if  the  program  prompts 
an  operator  to  make  a  number  of  entries,  those  en¬ 


tries  can  be  collected  to  form  an  operator  input  inter¬ 
val.  If  a  program  is  organized  as  a  series  of  single  in¬ 
tervals,  separated  in  such  way  that  the  operator  con¬ 
trols  the  sequence  of  or  time  between  intervals,  that 
program  could  be  considered  a  multiple  interval 
one. 

Within  each  interval,  the  user  must  be  able  to  ex¬ 
press  the  desired  output  in  terms  of  its  parts,  where 
each  part  can  be  set  up  or  carried  out  by  a  particular 
subroutine  block.  The  user  may  provide  new  subrou¬ 
tines  to  carry  out  some  output  procedure  if  the  ex¬ 
isting  subroutines  are  not  sufficient.  Only  those  parts 
that  are  not  continued  from  the  previous  interval 
need  be  set  or  run. 

The  user  must  distinguish  between  output  parts 
that  are  set  and  those  that  are  run.  Both  types  must 
be  initiated  by  the  controller.  The  distinction  arises  in 
the  output  behavior  when  the  controller  moves  to  a 
different  task.  Set  type  outputs  are  stable  in  the  sense 
that  their  maintenance  does  not  require  use  of  the 
controller.  Once  set,  such  outputs  remain  until  the 
controller  acts  to  change  or  remove  that  output  or 
until  power  is  turned  off.  Run  type  outputs  require 
continuous  use  of  the  controller  and  hence  will  tie  up 
the  controller.  Such  outputs  will  remain  only  as  long 
as  the  controller  continues  to  run  them  and  will  end 
when  the  controller  moves  to  another  task. 

A  brief  example  will  help  clarify  this  point.  An  IM 
sweep  derived  from  the  arbitrary  waveform  genera¬ 
tor  is  a  set  type  output.  Once  the  appropriate  subrou¬ 
tine  block  has  been  used  to  set  up  the  sweep,  the 
waveform  generator  and  auxiliary  switch  matrix  will 
remain  set  until  the  controller  acts  to  change  some¬ 
thing.  Until  then,  it  does  not  matter  what  the  control¬ 
ler  does;  the  controller  is  not  needed  to  maintain  that 
IM  sweep  modulation.  On  the  other  hand,  an  IM 
sweep  derived  from  the  controller  through  one  of  the 
subroutine  blocks  is  a  run  type  output.  The  controller 
would  be  lied  up  running  such  an  output,  and  the 
output  would  end  when  the  controller  moved  on  to 
its  next  task. 

Run  type  outputs  can  be  seen  as  those  that  require 
a  dedicated  controller  to  run  a  rapidly  timed  series  of 
changes  of  simulator  devices.  The  devices  and 
changes  are  the  same  as  for  set  type  outputs,  but  the 
timing  of  individual  changes  is  rapid  compared  to  in¬ 
terval  times.  In  the  controller  run  fm  example,  the 
FM  sweep  is  achieved  by  having  the  controller  rapidly 
change  the  tune  frequency.  If  the  controller  were 
stopped  from  the  keyboard  while  running  such  a 
sweep,  the  last  tune  frequency  set  would  remain  set 
until  the  program  was  enabled  to  continue. 
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The  distinction  between  set  and  run  (or  set  and  tie- 
up)  is  important  when  the  user  comes  to  specifying 
the  order  of  parts  within  an  interval.  Since  the  con¬ 
troller  is  tied  up  by  run  type  outputs,  the  user’s  pro¬ 
gram  must  carry  out  any  needed  set  type  instructions 
before  reaching  a  run  type  instruction  in  that  interval 
(e.g.,  to  run  a  synchronous  hopping  noise  spot,  the 
user’s  program  sets  the  noise  spots,  carriers,  and 
power  levels  before  running  the  hop). 

The  distinction  between  set  and  run  is  also  useful 
when  conceptually  breaking  up  an  overall  output  into 
intervals.  Since  an  interval  corresponds  to  a  change 
in  the  simulator’s  status  and  a  run  type  output  mod¬ 
ulation  will  end  when  the  controller  stops  running  it, 
any  run  type  outputs  in  a  program  serve  as  natural 
interval  markers.  The  distinction  is  also  used  when 
deciding  the  parts  with  an  interval.  If  in  the  previous 
interval  a  modulation  has  been  set,  it  remains  present 
and  need  be  explicit  in  a  following  interval  only  if 
some  change  in  the  modulation  is  due  in  that  interval. 
If  a  run  type  modulation  output  has  been  run,  it  will 
have  ended  at  the  end  of  the  interval  in  which  it  was 
run  and  hence  is  no  longer  present  in  following 
intervals. 

Run  type  outputs  (and  any  other  tasks  that  will 
similarly  tie  up  the  controller)  require  some  running 
time  control  if  the  controller  is  not  to  be  completely 
lied  up.  Such  control  for  the  subroutine  blocks  is 
commonly  achieved  by  specifying  the  number  of  out¬ 
put  steps  at  a  specified  rate,  e.g.,  the  number  of 
sweeps  for  the  controller’s  fm  sweep,  or  the  number 
of  am  changes  for  the  controller’s  AM.  The  time 
then  spent  with  the  controller  tied  up  is  the  quotient 
of  the  number  of  steps  divided  by  the  rate  (the  num¬ 
ber  of  steps  can  be  specified  as  the  integer  product  of 
the  rate  and  tie-up  time).  In  the  case  of  one  subrou¬ 
tine  block  (“stepmod”),  the  rate  may  vary  from 
one  step  to  the  next  so  that  the  tie-up  time  is  implicit 
in  the  specified  number  of  steps,  while  in  another 
(“special”)  the  tie-up  time  is  passed  directly.  The 
subroutine  blocks  will  use  such  information  to  deter¬ 
mine  the  dwell  time  at  each  output  step,  allowing  for 
the  time  it  takes  the  controller  to  execute  the  instruc¬ 
tions  that  make  up  that  step. 

The  user  can  accurately  control  the  amount  of  time 
the  controller  is  tied  up  and  so  control  interval 
timing.  In  cases  where  a  run  type  output  should  ap¬ 
pear  as  if  it  were  set  to  run  forever,  the  user  can  speci¬ 
fy  some  very  large  number  of  steps  relative  to  the  rate 
(or  a  long  time  if  time  is  passed). 

The  user  may  control  the  time  spent  on  various  in¬ 
tervals  in  other,  more  general  ways  that  do  not  in¬ 
volve  the  number  of  output  steps  in  a  run  type  sub¬ 


routine  block.  In  some  tests,  the  desired  output  may 
be  a  sequence  of  set  modulations  with  no  run  type 
outputs  appearing.  The  most  direct  way  of  timing 
control  is  to  use  the  controller’s  wait  instruction. 
Waits  longer  than  the  T2.767  s  maximum  ot  the  wait 
instruction  can  be  reached  by  repeating  several  waits 
or  by  running  a  wait  loop.  The  user  may  also  access 
the  multiprogrammer’s  real-time  clock  for  either  rel¬ 
ative  or  absolute  timing. 

How  the  user  outlines  a  test  program  can  now  be 
summarized.  The  user  must  first  describe  the  desired 
test  output  form.  This  can  be  done  by  sketching  out 
the  desired  output  for  each  Rt  channel,  including 
time  changes  (on  the  level  of  “a  blinking  noise  spot 
on  one  channel,  a  swept  comb  on  another,  the  comb 
being  replaced  by  biphase  noise  after  an  interval”). 
The  user  may  allow  an  operator  to  choose  the  actual 
form  by  specifying  what  part  of  the  user  program  to 
run.  However,  to  write  a  program  the  user  may  treat 
each  such  operator-selected  option  as  if  ii  were  run 
directly  by  the  controller. 

The  user  must  next  determine  a  way  of  allocating 
the  simulator  rf  channels;  i.c. ,  given  the  desired  out¬ 
put  from  a  channel,  the  user  assigns  an  actual  Rt 
channel  as  the  output  source,  either  by  direct  (literal) 
or  indirect  (variable)  assignment.  The  Rt  channels  are 
allocated  on  the  basis  of  the  frequency  band  of  the 
desired  output.  Indirect  assignments  allow  an  opera¬ 
tor  to  specify  each  actual  source  at  the  time  the  pro¬ 
gram  is  used.  Only  one  VCO  may  be  active  in  an  rf 
channel. 

Next,  the  user  analyzes  the  overall  test  form  in 
order  to  conceptually  break  it  up  into  intervals.  The 
user  may  find  it  helpful  to  visualize  or  sketch  a  time 
behavior  chart  to  indicate  RF  channel  output  changes 
and  the  relative  liming  between  such  changes  (see 
Fig.  B-l).  The  origin  of  the  time  axis  would  corre¬ 
spond  to  initialization.  There  will  be  a  minimum  of  at 
least  one  interval  in  any  lest;  there  is  no  maximum. 

Each  interval  represents  a  notable  change  in  the 
simulator  status.  An  interval  may  involve  setting  or 
running  some  modulation  or  it  may  involve  no  out¬ 
put  changes  but  be  used  to  time  an  upcoming  change, 
run  some  lengthy  internal  calculation,  or  handle  tape 
access.  Since  an  interval  marks  a  change,  only  those 
set  devices  that  change  status  during  an  interval  need 
be  explicitly  present  in  that  interval’s  instructions. 

Having  determined  the  intervals,  the  user  considers 
each  rf  channel  separately  during  that  interval.  If 
there  are  no  set  changes  or  run  patterns  involving 
that  RF  channel,  it  can  be  left  as  is.  If  there  are 
changes  or  patterns,  the  user  must  break  the  desired 
result  into  its  parts.  Any  part  that  was  set  to  its  de- 
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Example  shows  output  form  with  three  intervals 

Figure  B-1  —  Interval  forms. 

sired  form  during  a  previous  interval  can  be  left  as  is. 
All  other  parts  must  be  set  to  their  new  form  and  run 
patterns  started  (set  type  outputs  are  always  handled 
before  a  run  type  output  in  the  same  interval). 
Determining  the  parts  of  each  interval’s  form  is 
equivalent  to  determining  the  output  setting  instruc¬ 
tions. 

Having  determined  the  overall  form  and  having 
broken  that  into  intervals  and  parts,  the  user  should 
know  from  the  parts  just  what  parameters  are 
needed.  The  user  must  then  decide  how  to  determine 
the  actual  parameters  to  be  used  (e.g.,  having  decided 
that  at  some  point  the  output  should  have  a  new 
noise  spot,  the  user  determines  what  RF  spot  band¬ 
width  and  video  filter  to  use).  This  may  range  from 
use  of  direct  literal  numbers  to  operator  entries  just 
before  each  output  instruction.  When  using  operator 
entries,  it  is  generally  easier  to  have  the  controller 
prompt  for  all  inputs  at  one  time.  The  user  should 
obviously  avoid  operator  entries  during  time-crucial 
periods  such  as  the  middle  of  a  run  type  output.  The 
user  may  set  up  a  prerecorded  data  array  containing 
the  usual  parameters  for  a  test  and  allow  an  interval 
just  after  initialization  for  the  operator  to  pass  on 
any  parameters  to  be  changed  from  the  usual  or 
default  values. 

With  the  output  setting  instructions  and  a  param¬ 
eter  determination  method  decided,  the  user  has  ihe 
basic  outline  of  a  test  program  intact.  The  necessary 
initialization  instructions  should  be  quite  straightfor¬ 
ward  and  can  simply  be  inserted  at  the  start  of  the 
user’s  program.  Table  B-l  outlines  the  general  struc¬ 
ture  of  a  program. 


Swept  comb  I 


Hopping  spot 


Table  B-1  -  New  user's  outline 


Dimension 
initialize 
Load  data 
For  each  interval: 

Determine  interval 

Determine  status  of  general  devices  (WI75s.  timer/ 
pacer  card,  external  generators;  this  is  usually 
implicit) 

For  each  RF  channel/group  of  RF  channels: 

If  active:  fix  status  of  set/type  devices  (VCO  select, 
noise  spots,  biphase  modulations,  etc.) 

(Only  changes  from  previous  interval  need  to  be 
explicit.) 

Else  skip 

Next  RF  channel/group  of  RF  channels 
If  olher  tasks  (e.g.,  file  loads,  printing,  checking): 
perform  task 

If  run  type  routines  used:  run 
Timing  control 
Next  interval 

There  are  a  number  of  additional  minor  areas  that 
a  user  should  cover  besides  the  major  areas  of  initiali¬ 
zation,  parameter  determination,  and  output  setting. 
Three  of  these  are:  status  tracking,  test  self-docu¬ 
mentation,  and  label  use. 

Status  tracking  is  usually  implicit  in  the  sequence 
of  output  settings,  which  is  well-defined  when  a 
known,  fixed  interval  sequence  is  used.  Some  lest 
programs,  however,  will  allow  an  operator  to  deter¬ 
mine  the  order  of  intervals,  as  is  the  case  in  a  demon¬ 
stration  program  that  through  use  of  the  controller’s 
user-defined  function  keys  allows  an  operator  to  ran¬ 
domly  combine  different  modulations.  In  such  cases 
the  user’s  program  will  need  explicit  status  tracking. 
Such  tracking  would  typically  involve  checking  if 
carriers  are  turned  on,  if  the  desired  VCO  in  each  RF 
channel  is  in  use,  and  (especially)  if  there  is  a  conflict 
between  using  an  arbitrary  waveform  generator  as  a 
pulse  source  or  an  fm  or  am  source.  If  one  of  the 
waveform  generators  has  been  set  up  for  fm  or  am,  it 
should  not  be  switched  into  an  RF  channel’s  pulse 
circuit,  since  the  waveforms  and  voltages  are  not 
compatible.  Status  tracking  can  be  done  by  mon¬ 
itoring  the  contents  of  Z  [  *  ] (see  Appendix  E)  and  by 
use  of  the  controller’s  flags  or  a  dedicated  array. 

Test  self-documentation  can  be  a  very  useful  part 
of  the  overall  documentation  (see  Appendixes  D  and 
I).  Typically  it  would  consist  of  using  the  control¬ 
ler’s  internal  printer  to  make  a  hard  copy  record  of 
the  parameter  values  used.  This  is  particularly  useful 
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when  an  operator  enters  parameter  values  from  the 
keyboard;  the  operator  entries  can  be  printed  as  en¬ 
tered,  which  makes  it  easier  for  the  operator  to  spot 
any  misentered  values.  Additional  information,  such 
as  a  message  indicating  the  test  form  in  use,  can  also 
be  printed  if  the  user  wishes.  The  self-documentation 
on  the  controller’s  printer  can  be  removed  and  kept 
in  an  operator’s  log  or  notebook  as  a  direct  record 
of  the  simulator’s  status  during  a  test. 

Label  use  can  make  a  test  program  much  easier  to 
understand,  debug,  modify,  or  use.  Suitable  labels 
can  be  used  to  delineate  the  program  tasks  of  each  in¬ 
terval  and  to  indicate  the  purpose.  The  user  ought  to 
include  a  good  label  on  line  0  of  any  program  to  serve 
as  an  identifier.  Labels  may  also  be  used  to  tag  loca¬ 
tions  from  which  an  operator  can  continue  a  pro¬ 
gram  after  a  fault-caused  crash  (see  Appendix  F).  On 
the  HP9825  controller,  labels  may  be  up  to  70  char¬ 
acters,  not  counting  the  colon  or  apostrophe  marks, 
so  there  is  no  trouble  with  forming  easy  to  under¬ 
stand  mnemonics  (though  shorter  labels  are  obvi¬ 
ously  more  memory  efficient  than  long  ones).  The 
only  really  notable  restriction  on  labels  is  that  each 
must  be  unique  and  the  user  must  avoid  using  any  of 
the  labels  already  in  use  by  the  subroutine  blocks  (see 
Table  3). 

Labels  have  an  obvious  usefulness  in  handling  pro¬ 
gram  branches.  Of  the  branching  instructions  avail¬ 
able  on  the  HP9825,  the  user  should  avoid  the  abso¬ 
lute  go  to  (gto  line  #)  because  it  makes  it  awkward  to 
modify  a  program  by  adding  or  deleting  lines  or  to 
reorder  the  program  sequence.  The  relative  go  to  (gto 
#  of  lines)  would  generally  be  avoided  because  it  is 
easy  to  drop  plus  signs  when  typing  that  instruction, 
converting  it  to  an  absolute  go  to  and  increasing  any 
debugging  workload.  The  relative  go  to  may  be  use¬ 
ful  in  rare  cases  where  its  slight  speed  advantage  over 
the  jump  instruction  is  needed.  Normally,  the  user 
will  use  the  jump  and  labeled  go  to  (gto  “label”)  in¬ 
structions  to  handle  branching.  The  jump  instruction 
is  space-efficient  and  allows  variables  or  expressions 
as  its  argument.  Any  jump  of  more  than  about  seven 
program  lines  should  be  replaced  by  a  labeled  go  to 
because  longer  jumps  are  hard  to  follow  when 
reading  or  debugging  a  program  and  may  be  missed 
if  the  program  is  modified  by  adding  or  deleting  a 
few  lines.  The  label  used  in  such  a  replacement  can  be 
any  arbitrary  symbol  (an  example  is  in  the  “enter” 
subroutine  block).  Labeled  go  to’s  (gto  “label") 
with  gooJ  mnemonics  should  be  used  when  branch¬ 


ing  between  intervals  or  other  main  program  ele¬ 
ments. 

There  is  one  other  general  suggestion  that  the  user- 
may  wish  to  follow  when  preparing  programs,  partic¬ 
ularly  long  multi-interval  ones  A  program  may  be 
organized  so  that  the  main  program  consists  basically 
of  subroutine  calls  (a  somewhat  similar  arrangement 
would  be  a  series  of  labeled  go  to’s  with  returns  to 
some  instruction  that  determines  the  next  label).  Sub¬ 
routines  may  be  used  even  if  the  subroutine  is  only 
used  once.  The  advantages  of  this  approach  are 
better  readability,  ease  of  modification,  and  portabil¬ 
ity.  It  can  be  easier  to  read  and  undet stand  the  pro¬ 
gram  when  the  basic  instructions  (the  subroutine 
calls)  can  be  collected  in  one  group  of  program  lines, 
especially  if  good  mnemonics  are  used  for  the  sub¬ 
routine  name  labels.  Organizing  the  program  as  a 
group  of  subroutine  calls  makes  it  easier  to  add  or  de¬ 
lete  lines  from  one  procedure  without  affecting  the 
program  flow  from  one  procedure  to  the  next;  fewer 
jump  branches  need  be  modified  (a  procedure  is  a 
group  of  instructions  to  perform  some  particular 
task).  A  subroutine-based  structure  also  makes  it 
easier  to  use  a  particular  procedure  in  other  programs 
by  simply  using  the  subroutine  that  performs  that 
procedure.  Such  transfers  are  made  easier  if  the  sub¬ 
routines  are  written  using  local  p-number  variables 
rather  than  global  variables  and  if  good  mnemonic 
name  labels  are  used  (see  Appendix  D  for  more 
details). 

It  is  hoped  that  the  reader  will  have  gathered  the 
general  principles  of  preparing  a  test  program,  which 
should  remain  valid  through  simulator  upgrades  and 
software  changes.  Presently  the  simulator  is  set  up  so 
that  it  is  a  one-way  device,  from  controller  to  simula¬ 
tor  to  test  darkroom.  If  a  look-through/self¬ 
measurement  or  responsive  capacity  is  added  to  the 
simulator,  the  same  sort  of  interval  structure  can  be 
used;  one  interval  could  carry  out  a  look-through  and 
the  controller  could  then  responsively  decide  which 
output  interval  should  be  next,  based  on  what  was 
measured. 

How  easy  or  difficult  it  is  to  prepare  a  test  program 
will  depend  on  the  desired  lest  and  on  the  user’s  ex¬ 
perience  with  using  the  simulator.  Before  starting  a 
test  program  from  the  beginning,  the  user  should 
check  previously  prepared  demonstration  and  test 
programs  to  see  if  any  can  be  used  as  they  are,  in 
combination,  or  with  slight  modifications,  to  get  the 
desired  output.  A  substantial  library  of  test  programs 
will  be  developed  for  the  user  to  consider. 
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APPENDIX  C 

SUBROUTINE  PARAMETER  PASSING 


To  use  a  subroutine  properly,  several  conditions 
must  be  met:  it  must  be  the  right  subroutine  for  the 
desired  effect;  it  must  be  called  at  the  appropriate 
time  and  place  in  the  user's  program;  it  must  be 
given  the  right  parameter  values  for  the  desired  ef¬ 
fect;  and  the  parameter  values  must  be  in  the  right 
form. 

The  determination  of  desired  effects,  timing,  and 
parameter  values  is  up  to  the  user  and  will  depend  on 
the  lest  (see  Appendix  B).  This  appendix  describes 
how  the  user  passes  parameters  to  a  subroutine.  It  in¬ 
cludes  a  number  of  rules  and  suggestions  that  partic¬ 
ularly  apply  to  those  tests  in  which  the  user  allows  an 
operator  to  specify  the  values  of  the  parameters  to  be 
passed.  The  principles  of  this  appendix  apply  to  any 
subroutine  the  user  writes,  as  well  as  to  the  subrou¬ 
tine  blocks. 

The  user  (the  one  who  writes  new  test  programs) 
must  be  familiar  with  the  HP9825  controller’s  HPL 
language,  whereas  the  operator  (the  one  who  runs  the 
test  program)  need  not  be  (the  user  and  operator  will 
not  necessarily  be  the  same  person).  In  passing  par¬ 
ameters,  the  user  must  follow  some  well-defined  rules 
concerning  the  form  and  order  of  the  parameters;  the 
operator,  however,  can  be  more  flexible  in  entering 
parameter  values  if  the  user  has  provided  the  appro¬ 
priate  programming.  Such  programming  will  in¬ 
crease  the  workload  of  the  user  but  greatly  decrease 
that  of  the  operator,  when  operator  entries  are 
used. 

Subroutine  parameters  must  be  passed  in  a  rigor¬ 
ously  defined  order.  If  a  subroutine  is  supposed  to  be 
called  with  duty  cycle  and  period,  the  user  must  give 
the  parameters  in  that  order,  not  as  period  and  duty 
cycle.  The  parameter  order  for  each  subroutine  block 
can  be  found  in  the  subroutine  descriptions  in  Ap¬ 
pendixes  N  and  O.  When  the  user  wr'tes  new  subrou¬ 
tines,  it  is  up  to  the  user  to  keep  track  of  the  param¬ 
eters  and  their  order,  especially  if  the  new  subrou¬ 
tines  are  to  be  used  in  other  test  programs.  This  is 
easier  to  do  if  the  subroutines  use  a  consistent  ap¬ 
proach  in  definin';  the  order  of  the  parameters,  such 
as  using  the  f;  rrameter  to  specify  either  the  VCO 
or  the  band  a  subroutine  that  affects  only  one 
VCO  or  one  band. 

The  user  cannot  pass  characters,  strings,  or  entire 
art  as  s  to  a  subroutine.  Passed  parameters  must  be 


literal  numbers,  simple  variables,  r-numbers,  or 
array  elements;  p-nunibers  can  be  passed  from  one 
subroutine  to  another.  Passed  parameters  may  also 
be  expressions,  a  particularly  useful  feature.  Scaled 
numbers  cannot  be  passed  as  such  but  must  be  recast 
as  an  unsealed  number  or  an  expression.  For  exam¬ 
ple,  the  user  cannot  pass  a  parameter  value  of  5  MH/ 
by  writing  5  MHz.  but  he  may  pass  it  as  5M  if  the 
simple  variable  M  has  been  assigned  the  value  of  one 
million.  The  figure  of  5  MHz  could  also  be  passed  as 
5e6  or  5000000  or  by  passing  any  variable  or  expres¬ 
sion  that  has  that  value. 

The  parameters  used  within  a  subroutine  will  have 
a  scale  that  the  user  must  be  aware  of  in  passing  par¬ 
ameters;  e.g.,  if  a  subroutine  requires  a  parameter  to 
be  in  milliseconds,  the  user  must  pass  milliseconds, 
not  seconds.  The  subroutine  blocks  generally  treat 
passed  parameters  as  unit-scaled  values.  Frequencies 
and  bandwidlhs  are  given  in  hertz,  rates  in  hertz  or 
steps/second,  and  attenuations  in  decibels.  An  excep¬ 
tion  is  that  periods  are  specified  in  milliseconds  while 
running  or  tie-up  times  are  in  seconds.  Frequencies 
and  frequency-related  parameters  such  as  band 
widths  or  rates  are  given  in  hertz  rather  than  mega¬ 
hertz  or  gigahertz  to  remain  consistent  regardless  of 
the  particular  VCO  band  involved.  Tune  frequencies 
would  normally  be  expressed  in  megahertz  in  a  type  I 
Rl-  channel  and  in  gigahertz  in  a  type  II  channel. 
However,  by  requiring  both  to  be  passed  in  hertz,  the 
subroutine  blocks  involved  in  setting  tune  frequen¬ 
cies  (“fset”,  “fval#”)  can  use  the  same  instruc¬ 
tions  for  both  without  requiring  the  user  to  remem¬ 
ber  to  scale  one  group  of  frequencies  and  not  the 
other.  Bandwidlhs  (especially  noise  spot  bandwidths) 
would  normally  be  expressed  in  megahertz,  but  they 
are  passed  in  hertz  to  remain  consistent  with  the  fre¬ 
quency  scale.  Rates  are  given  in  hertz  for  the  same 
reason.  Since  the  subroutine  blocks  use  a  unit  scale 
for  all  parameters  (except  periods),  the  user  can 
assume  the  same  scale  for  all  related  parameters.  The 
user  should  employ  a  similar  scaling  rationale  when 
writing  new  subroutines,  especially  those  used  in 
more  than  one  test  program. 

It  should  be  noted  that  an  operator’s  entries  do 
not  have  to  have  the  same  scale  as  that  required  by 
the  passed  parameters.  The  user’s  program  may 
allow  entries  in  whatever  units  seem  most  appropri- 
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ale  for  an  operator  to  use  and  then  scale  those  entries 
before  passing  them  to  the  subroutines.  This  is 
covered  in  more  detail  below. 

The  required  forms  for  other  subroutine  block  pa¬ 
rameters  are  fairly  obvious,  with  attenuations  in  deci¬ 
bels,  step  rates  in  steps/second,  and  so  on.  The  arbi¬ 
trary  waveform  generator  block  rates  and  function 
numbers  can  best  be  understood  in  the  context  of  j 
using  the  W175  generators  (see  Appendix  H).  Switch 
codes  are  used  for  the  nulse  and  biphase  circuits  and 
the  fm  and  am  modulation  switch  matrices  because 
no  alphanumeric  can  be  directly  passed;  the  codes  are 
the  actual  codes  sent  to  the  necessary  switches, 
though  this  is  not  an  essential  feature  (see  Table  C- 
1). 

One  parameter  form  that  may  lead  to  questions  is 
that  of  the  VCO  number  (see  Tables  C-2  and  C-3). 
Most  subroutine  blocks  affect  one  VCO,  with  the 
VCO  indicated  by  the  first  parameter  passed  (the 
band  number  serves  a  similar  purpose  in  subroutines 
that  affect  all  the  VCOs  in  one  band).  The  VCO 
number  is  a  short  way  of  specifying  which  VCO  is 
affected.  This  information  is  used  in  determining  the 
proper  multiprogrammer  card  addresses  for  the  RF 
channel  involved.  It  is  also  used  in  frequency-depen¬ 
dent  subroutine  blocks  to  find  the  right  data  tables, 
check  parameter  limits,  and  otherwise  distinguish  be¬ 
tween  the  two  VCOs  in  each  rf  channel.  A  single 
VCO  number  is  easier  to  use  than  separate  numbers 
for  the  RF  channel  and  the  VCO  in  that  RF  channel. 
The  VCO  number  of  each  VCO  can  be  remembered 
easily  by  noting  each  VCOs  position  in  the  standard 
rack  arrangement  (see  Table  C-2).  It  may  be  noted 
that  several  of  the  subroutines  could  as  readily  be 
specified  by  the  rf  channel  number.  The  VCO 
number  is  used  throughout  in  order  to  remain  consis¬ 
tent;  the  user  does  not  need  to  remember  if  a  subrou¬ 
tine  block  uses  a  VCO  number  or  rf  number  but  can 


just  remember  the  former.  However,  the  user  will 
have  to  remember  if  a  subroutine  uses  a  VCO 
number  or  band  number;  this  can  be  done  by  remem¬ 
bering  if  the  subroutine  affects  one  VCO  or  all  of 
those  in  a  band.  The  user  should  also  remember  that 
while  the  VCO  number  (or  band  number)  is  normally 
the  first  passed  parameter,  the  arrangement  differs  in 
those  subroutine  blocks  that  may  affect  a  variable 
number  of  VCOs  in  different  bands  (such  as  "DC 
175,”  “T/P”).  In  these  cases,  the  VCOs  are  the 
last  parameters  passed.  The  user  should  use  a  similar 
approach  in  writing  new  subroutines  (see  Appendix 
D).  It  should  be  noted  that  an  operator  may  specify  a 
VCO  by  rf  channel  number  and  VCO  letter  if  the 
subroutine  “enter”  is  used. 

There  are  a  number  of  methods  by  which  the  us¬ 
er’s  program  may  find  values  for  the  passed  param¬ 
eters.  Any  of  these  methods  may  be  combined  in  a 
program.  The  most  direct  way  of  specifying  values  is 
to  use  literal  numbers.  This  method  is  suitable  when 
the  test  parameter  values  do  not  change  between  test 
runs.  However,  literal  numbers  are  tedious  to  change 
if  the  user  wishes  to  vary  the  values  because  the  user 
must  then  rewrite  every  line  with  a  changed  param¬ 
eter  value. 

The  more  usual  methods  of  passing  parameter 
values  use  variables  in  ihe  actual  subroutine  calls, 
with  the  methods  differing  in  how  they  assign  values 
to  those  variables.  It  may  be  noted  that  if  the  user 
considers  it  easier  to  specify  a  parameter  in  a  form 
different  from  that  required  by  the  subroutine  (such 
as  specifying  a  blinking  signal’s  rate  rather  than 
period),  the  necessary  conversion  expression  can  it¬ 
self  be  passed  as  part  of  the  subroutine  call,  or  the  ex¬ 
pression  may  be  carried  out  before  the  call  with  the 
result  assigned  to  the  variable  being  passed.  The 
user’s  choice  in  such  cases  can  be  decided  by  consid¬ 
ering  which  form  would  be  easier  to  read,  subject  to 


Table  C-1  -  Switch  codes. 


Code  No. 

pulse 

biph 

auxmod ‘ 

AMaux 

0 

r  arrier  on 

20  MHz  comb 

Off 

Off 

1 

10  Hz,  50°7o  sq. 

10  MHz  comb 

External 

External 

2 

100  Hz,  50<7o  sq. 

5  MHz  comb 

D/A  FM 

D/A  AM 

3 

W175  (A) 

Carrier  on 

W175  (B) 

W175  (A) 

4 

WI75  (B) 

40  MHz  biphase 

- 

- 

5 

T/P  card 

20  MHz  biphase 

- 

- 

6 

External 

10  MHz  biphase 

- 

- 

7 

Carrier  off 

Carrier  off 

- 

- 

*  auxmod  is  (lie  FM  auxiliary  modulation  switch  control. 
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Table  C-2  -  VCO  number  information. 


VCO  No.  Band  No.  Rl No. 


1  0  I 

2  I  I 

2  0  2 

4  I  2 

5  0  3 

6  I  3 

7  2  4 

8  3  4 

9  2  5 

10  3  5 

11  2  6 

12  3  6 


the  constraint  that  an  expression  passed  in  a  subrou¬ 
tine  call  must  be  brief  enough  so  that  the  subrou¬ 
tine’s  parameter  list  will  fit  on  one  program  line 
(there  are  no  continuation  lines  for  parameter  lists  in 
HPL). 

Variable  assignments  may  be  carried  out  as  pari  of 
the  program  or  it  may  be  done  in  advance.  Assign¬ 
ments  done  as  part  of  the  program  are  somewhat 
similar  to  use  of  literal  numbers;  however,  by  col¬ 
lecting  all  assignment  instructions  into  one  part  of 
the  program  (generally  just  after  initialization),  it  be¬ 
comes  easier  for  the  user  to  change  values  than  if  ihe 
user  had  literal  numbers  scattered  throughout  the 
program.  This  approach  is  suitable  for  cases  in  which 
a  test  is  usually  run  with  the  same  parameter  values, 
with  only  occasional  changes, 

A  more  general  approach  is  to  assign  values  to  var¬ 
iables  in  advance  of  a  test.  The  variables  are  then 
saved  on  tape,  with  the  user's  program  loading  the 
variable  data  as  part  of  initialization  (see  Appendix 
B).  By  preparing  several  such  taped  data  files  and 
allowing  an  operator  to  select  which  one  is  used,  the 
user  can  provide  a  rapid  and  convenient  way  of 


Letter 

Code 

f 

*  min 

A 

250  MHz 

500  MHz 

B 

500  MHz 

1  GHz 

A 

250  MHz 

500  MHz 

B 

500  MHz 

1  GHz 

A 

250  MHz 

500  MHz 

B 

500  MHz 

1  GHz 

A 

1G  Hz 

2  GHz 

B 

2  GHz 

4  GHz 

A 

1  GHz 

2  GHz 

B 

2  GHz 

4  GHz 

A 

1  GHz 

2  GHz 

B 

2  GHz 

4  GHz 

changing  the  test  parameter  values.  This  approach  is 
appropriate  when  a  test  is  usually  run  with  the  same 
values;  multiple  data  files  allow  easy  changes  be¬ 
tween  sets  of  values.  A  separately  assigned  data  file 
can  also  save  program  memory  space  by  carrying  out 
the  assignments  outside  the  program  proper  and  be 
conceptually  easier  to  understand.  When  using  this 
approach,  the  user  is  urged  to  use  an  array  (or  strings 
or  the  r-numbers)  for  the  taped  variables  and  avoid 
using  the  simple  variables.  If  simple  variables  are 
used  for  the  taped  variables,  the  variable  assignments 
will  be  thrown  off  if  the  test  program  dimensioned 
the  simple  variables  in  a  different  order  than  was 
used  when  the  variables  were  assigned  (see  the 
HP9825  reference  manuals).  If  simple  variables  are 
used  to  hold  taped  data,  then  the  simple  variables 
should  be  explicitly  dimensioned  in  the  same  order 
for  both  the  test  program  and  the  assignment  of  vari¬ 
ables.  The  user  must  also  beware  that  if  ordinary  var¬ 
iables  are  taped  and  then  loaded  into  r-numbers  (or 
vice  versa),  the  order  will  be  reversed  (see  the  HP9825 
reference  manuals).  The  r-numbers  are  useful  for 
variable  length  data  files  since  they  do  not  need  to  be 
dimensioned. 
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Table  C-3  -  VCO  number  algorithm  values. 


ICO 

No. 

1 

rt 

No. 

1 

Band 

No. 

0 

Band 

Mult. 

1 

Tune 
Slot  No. 

2 

/  OH'/ 

High 

1 

Y 

1 

1 

2 

2 

1 

3 

Y 

0 

1 

2 

2 

4 

2 

1 

2 

2 

0 

s 

3 

0 

1 

3 

1 

6 

3 

1 

2 

3 

1 

7 

4 

2 

4 

3 

2 

8 

4 

3 

8 

3 

0 

9 

5 

2 

4 

4 

1 

10 

5 

3 

8 

4 

1 

11 

6 

2 

4 

4 

2 

12  6  3 

VCO  No.:  X 

RF  No.:  int  (X/2  +  0.5) 

8 

4 

0 

Low/high:  ini  (X  mod  4/2  +  0.5) 

BandNo.:l  +  2«X  -  I)/6)  -  Xmod2 
Band  mull.:  2l(band  No.) 

Tune  slot  No.:2  +  int((X  —  0.5)/4) 

Note:  Rl  function  control  word  slot  No.  -  RF  No.  +  4 

The  user’s  program  may  also  allow  an  operator  to 
specify  data  values.  This  approach  is  the  most  ap¬ 
propriate  whenever  value  changes  are  anticipated 
more  often  than  occasionally.  For  operator  entries 
there  are  a  number  of  suggestions  that  fall  in  four 
categories:  prompting,  default  values,  checking,  and 
tracking. 

Prompting  the  operator  can  identify  what  variable 
is  involved  and  the  allowable  form  and  range  of  the 
variable  value.  Prompts  are  closely  tied  to  the  entry 
scheme  selected  by  the  user.  Entries  almost  always 
would  be  made  with  a  simple  one  entry  per  prompt 
scheme,  since  this  will  be  both  the  easiest  to  write  and 
the  easiest  to  use,  expecially  for  a  new  operator. 
Other  entry  schemes  (such  as  a  coded  string  entry, 
allowing  multiple  entries  in  any  order  at  the  same 
time)  may  be  found  useful  in  certain  cases,  but  gener¬ 
ally  the  operator  will  make  one  entry  at  a  time, 
guided  by  prompt  messages. 

It  should  be  noted  that,  for  very  long  entry  lists. 


the  operator  need  not  go  through  each  entry.  The 
user  may  insert  option  questions,  allowing  the  opera¬ 
tor  to  end  the  prompted  inputs  when  the  question  is 
reached;  the  user  could  also  set  up  the  prompts  so 
that  a  certain  reply  will  end  the  inputs  whenever  that 
reply  is  made. 

Prompted  inputs  typically  would  all  be  made  at 
one  time  during  a  test  program,  after  initialization 
and  before  the  actual  output  began.  During  such  an 
input  interval,  the  program  would  collect  all  the  data 
needed  for  the  output  intervals;  the  test  would  then 
proceed  without  requiring  further  operator  attention. 
Inputs  might  also  be  made  between  intervals  if  the 
time  between  intervals  is  not  fixed.  The  only  major 
restriction  on  prompted  inputs  is  that  in  order  to 
avoid  timing  problems,  p.ompting  should  not  be 
done  during  a  timed  output  run  or  during  the  middle 
of  an  interval. 

Prompts  should  involve  at  least  an  enter  statement 
message  identifying  what  sort  of  value  should  be  en¬ 
tered.  Bare  prompts  (those  with  no  message)  should 
be  used  only  when  preparing  taped  data  in  advance 
of  a  test,  and  then  only  when  it  can  be  assumed  that 
the  user/operator  knows  the  program  well  enough  to 
identify  the  purpose  of  each  variable.  It  should  be 
noted  that  enter  statement  messages  cannot  contain 
variable  display  elements  but  must  be  a  fixed  mes¬ 
sage.  The  user  may  use  conditional  enters,  each  with 
a  different  message,  if  it  seems  appropriate. 

More  commonly,  variable  elements  of  a  prompt 
message  would  be  given  to  the  operator  by  using  the 
display  statement  just  before  the  enter  statement. 
Any  number  of  display  messages  can  be  used  for  a 
single  prompt,  though  it  is  generally  best  to  use  the 
shortest  message  that  will  convey  the  desired  mean¬ 
ing;  long  messages  will  become  tedious,  especially 
after  the  first  time  an  operator  runs  the  test.  When 
the  display  statement  is  used  in  this  context,  the  time 
spent  on  each  display  should  be  kept  short  (a  message 
that  seems  too  fast  on  the  first  run  of  a  test  will  seem 
much  slower  on  later  runs).  The  stop  instruction 
could  be  used  instead  of  a  wail  and  the  operator  in¬ 
structed  to  press  the  CONTINUE  key  to  self-time  the 
messages;  however,  this  may  confuse  the  operator  in¬ 
to  unintentionally  pressing  CONTINUE  at  the  enter 
statement  as  well  as  the  displays.  This  procedure  is 
probably  better  suited  to  dedicated  help  programs 
(covered  below).  Displays  are  normally  preferred  to 
the  printer  for  prompt  messages  because  the  printer  is 
slower,  uses  paper,  breaks  up  the  form  of  any  contin¬ 
uing  self-documentation  (see  below  and  Appendix  1), 
and  soon  becomes  very  tedious,  especially  for  repeti¬ 
tious  prompt  messages.  As  an  example  of  a  variable 
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element  in  a  prompt  message,  suppose  the  user’s 
program  prompts  the  operator  to  enter  a  frequency. 
A  display  statement  would  show  the  frequency  limits 
(which  would  vary  depending  on  which  VCO  is 
used),  while  the  enter  statement  message  would 
prompt  for  the  frequency  value. 

Prompt  messages  should  be  kept  as  simple  as  pos¬ 
sible  to  avoid  slowing  down  the  speed  and  increasing 
the  size  of  a  program.  Ideally  a  prompt  message 
would  fit  within  the  HP9825’s  1-line  32  character 
display.  Some  abbreviation  is  useful  if  it  is  not  over¬ 
done.  Despite  the  display  size  limitations,  it  is  possi¬ 
ble  to  fit  satisfactory  operator  information  into  the 
enter  message  alone  so  that  display  messages  are 
often  not  needed. 

It  was  mentioned  earlier  in  this  appendix  that  the 
operator  is  allowed  to  enter  scaled  numbers,  with  the 
program  converting  that  entered  number  to  the  un¬ 
sealed  form  required  by  the  subroutine  blocks.  Thus, 
in  entering  a  frequency,  the  operator  can  specify  it  in 
units  of  megahertz  if  that  is  convenient.  If  a  probable 
scale  is  known  in  advance  (for  example,  as  it  would 
be  for  a  data  calibration  program),  the  operator  can 
be  prompted  to  enter  a  number  directly  in  that  scale 
(e.g.,  5  for  5  MHz).  The  user  may  wish  to  provide 
corrections  for  obviously  miskeyed  entries  in  this  sort 
of  input  (e.g.,  if  the  operator  were  prompted  to  enter 
a  megahertz  frequency  measurement  while  cali¬ 
brating  the  500  MHz  to  1  GHz  band  and  a  value  of  I 
were  entered,  the  program  might  conclude  that  the 
operator  meant  to  enter  1  GHz  or  1000  MHz,  and  the 
program  could  rescale  the  entered  value  accord¬ 
ingly). 

More  generally,  the  user's  program  would  prompt 
the  operator  to  enter  a  value  with  the  scale  factor 
attached  (e.g.,  3.2g  for  3.2  GHz).  The  user’s  pro¬ 
gram  would  accept  the  operator’s  value  by  entering 
it  to  U$  and  then  using  the  “enter”  subroutine 
function  block  to  convert  that  value  to  a  unit  scaled 
form  (see  Appendix  O),  the  return  from  “enter” 
being  used  to  set  up  the  variable  actually  passed  to 
the  other  subroutine  blocks. 

The  “enter”  subroutine  (not  to  be  confused  with 
the  enter  statement)  would  be  part  of  the  normal 
handling  of  operator  inputs.  It  is  therefore  important 
to  advise  the  operator  that  the  subroutine  will  not 
support  expressions  sent  through  the  CONTINUE 
key,  unlike  entries  sent  directly  to  a  variable  rather 
than  to  U$.  If  expressions  are  used,  they  must  be 
evaluated  by  using  EXECUTE  before  CONTINUE, 
with  the  expression  either  being  unit-scaled  or  the 
scale  indicator  added  with  the  edit  keys  after  EXE¬ 
CUTE. 


Also,  when  using  the  “enter''  subioutine.  the 
user  should  clear  U$  before  the  enter  statement  to  en¬ 
sure  that  only  the  operator’s  response  is  in  LJS  when 
“enter”  is  used  (US  is  used  by  several  other  subrou¬ 
tines;  see  Appendixes  E  and  O).  US  inputs  should  be 
terminated  to  avoid  string  errors;  for  numerical  in¬ 
puts  using  “enter,”  the  full  length  of  the  display  is 
used.  The  basic  form  is: 

“  “  —  U$;  ent  “message",  US  1 1 .32 ) 

‘enter’  —(variable) 

US  can  also  be  used  for  non-numeric  operator  en¬ 
tries.  The  operator  could  be  asked  to  specify  a  branch 
or  to  answer  a  yes/no  question,  and  the  reply  evalu¬ 
ated  as  a  string.  In  most  such  cases,  only  the  first 
reply  character  is  significant  and  need  be  examined. 
For  example,  to  ask  the  operator  a  ves  no  type 
question,  the  basic  form  is; 

“  “  —  US;  ent  “message”,  US  [1.1  1 
if  cap  (US  1 1.1  1)  =  "S'";  gto  “yes” 

"not  yes": 

Default  values  should  be  considered  an  essential 
pari  of  an  operator  prompt.  The  controller  will  auto¬ 
matically  set  Hag  13  if  CONTINUE  is  pressed  with 
no  data  entered  at  an  enter  statement  and  will  clear 
flag  13  if  data  are  entered.  The  user's  program  can 
Ihus  tell  if  the  operator  entered  anything  in  reponse 
to  a  prompt.  By  checking  flag  13  and  assigning  a 
default  value  to  the  appropriate  variable  if  it  is  set, 
the  user’s  program  can  allow  an  operator  in  effect  to 
skip  over  an  entry,  without  requiring  the  operator  to 
enter  anything. 

This  feature  is  particularly  useful  when  the  opera¬ 
tor  is  offered  a  long  list  or  menu  and  the  operator 
only  wishes  to  make  one  or  two  changes.  By  pressing 
CONTINUE  at  the  unwanted  prompts,  the  operator 
can  very  rapidly  go  through  a  list,  pausing  only  to 
enter  values  at  prompts  for  parameters  to  be  changed 
from  some  standard  value  (the  operator  does  not  nec¬ 
essarily  have  to  know  the  defaults).  The  same  effect 
would  be  obtained  if  the  passed  variables  are  first  set 
with  the  standard  values  (perhaps  by  using  laped  data 
as  mentioned  above)  and  flag  13  checked  at  each 
prompt  to  see  if  any  manipulations  (such  as  calling 
“enter”  to  get  the  U$  contents  into  a  variable)  are 
needed. 

When  the  operator  makes  an  entry,  the  user’s  pro¬ 
gram  should  generally  check  that  the  parameter  is 
legal  and  within  range.  Such  checking  often  amounts 
to  duplicating  some  of  the  checks  carried  out  by  the 
subroutine  blocks.  It  is  obviously  easier  to  recover 
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from  a  bad  parameter  if  it  is  found  before  being 
passed  and  causing  the  system  to  crash. 

There  are  other  checks  not  carried  out  by  the  pres¬ 
ent  subroutine  block  software  that  may  be  needed  for 
some  tests.  A  noise  spot  may  be  legally  set  at  one  tune 
frequency  but  result  in  a  bad  output  if  the  tune  center 
is  changed  or  swept.  The  pulse  circuit  switch  of  an  Ri 
channel  may  be  set  to  feed  in  the  signal  from  one  of 
the  arbitrary  waveform  generators  without  reference 
to  how  that  generator  is  set.  There  are  three  functions 
(I  M,  am,  pulse)  for  the  two  arbitrary  generators,  so 
some  way  is  needed  to  check  what  each  generator  is 
used  for  (this  sort  of  check  is  usually  implicit  in  the 
program  but  may  need  to  be  done  explicitly  if  a 
program  allows  the  operator  to  control  multiple 
branching). 

Checking  can  be  done  implicitly  when  fixed  or  de¬ 
fault  values  are  used;  explicit  checks  should  be 
carried  out  on  all  operator  inputs.  The  logical  place 
10  carry  out  explicit  data  checks  is  where  the  inputs 
are  made;  a  detected  bad  parameter  can  then  be  re¬ 
jected  while  the  operator  is  still  present  and  thinking 
of  that  input.  Checks  would  normally  be  fairly 
simple  and  involve  testing  to  see  if  the  value  is  within 
some  set  of  fixed  or  calculated  limits  (calculated 
limits  allow  greater  flexibility  than  fixed  ones  and  can 
be  changed  to  agree  with  earlier  inputs).  If  the  opera¬ 
tor’s  value  is  bad,  a  display  message  to  that  effect 
can  be  shown,  with  the  program  then  jumping  back 
to  the  input  prompt.  The  general  form  is: 

dsp  “message”;  wait  (time) 

“  “  —  US;  ent  “message”,  US  [  1,32 1 
if  fig  13;  (default)  —  variable;  jmp  (next) 
if  (‘enter’  —  variable)  .  .  .  (within  limits);  jmp 
(next) 

dsp  “correction  message”,  wait  (lime);  jmp 
(enter  US) 

“next”: 

When  checking  operator  entries,  the  user  may  wish 
to  carry  out  checks  other  than  value  limit  ones.  For 
instance,  if  dealing  with  a  very  long  list,  the  user’s 
program  may  designate  some  symbol  to  serve  as  a 
terminator;  each  input  check  would  look  for  that 
symbol  and,  if  found,  go  to  the  next  interval  after  the 
operator  inputs.  The  user  may  also  include  a  help 
file;  when  the  appropriate  symbol  is  found,  the  pro¬ 
gram  would  carry  out  a  dedicated  sequence  using 
either  the  printer  or  the  display  to  inform  and  other¬ 
wise  help  the  operator. 

A  help  file  will  be  most  efficient  if  taped  separately 
from  the  program  so  that  it  would  occupy  memory 
space  only  when  it  is  needed.  Use  of  a  separate  help 


file  requires  thai  the  user  keep  explicit  track  of  the 
line  numbers  at  which  the  help  file  and  the  program 
should  continue,  since  the  present  controller  has  no 
readily  accessible  capability  to  save  a  program  line 
number  (this  capability  may  be  added  in  a  future  up¬ 
grade).  Explicit  line  numbers  can  make  it  aw  kward  to 
modify  a  program.  The  user  might,  in  theory,  manip¬ 
ulate  the  error  recovery  routine  in  order  to  save  a  line 
number  by  deliberately  causing  an  error.  The  recov¬ 
ery  routine  would  have  to  check  if  the  error  were 
deliberate;  if  so,  the  routine  would  handle  the 
loading  of  the  help  file,  with  recovery  being  based  on 
the  contents  of  the  error  line  (erl)  label.  This  would 
still  require  explicit  line  numbers  within  the  recovery 
routine  and  would  increase  the  si/e  and  complexity  of 
a  test  program  and  decrease  the  speed  in  return  for  a 
marginal  improvement  in  ease  of  debugging  a  test 
program.  In  practice,  manipulation  of  the  error  re¬ 
covery  routine  is  not  worthwhile. 

Help  files  should  be  needed  only  for  long,  compli¬ 
cated  programs  intended  for  use  by  more  than  one 
operator  and  do  not  take  the  place  of  documenting  a 
test  program  (see  Appendix  I).  Help  files  and  the 
number  of  data  checks  carried  out  by  the  user’s  pro¬ 
gram  will  depend  on  the  user’s  perception  of  the  op¬ 
erator’s  skill  and  needs,  the  amount  of  available 
memory  space,  and  the  preparation  time  available 
for  a  test  program. 

The  user’s  program  should  keep  track  of  an  oper¬ 
ator’s  entries  beyond  the  point  where  they  are  passed 
to  the  subroutine  blocks.  Partially  this  is  so  that  the 
program  can  carry  out  later  data  checks;  it  is  gener¬ 
ally  more  appropriate  in  documenting  a  test  run.  The 
user’s  program  should  keep  track  of  parameter 
values  at  least  long  enough  for  the  operator  to  get  a 
record  of  the  values  used  in  the  test.  The  controller’s 
internal  printer  can  be  used  to  record  parameter 
values.  Values  could  be  printed  as  they  are  entered, 
which  is  particularly  appropriate  when  the  operator 
has  some  control  over  the  next  step  of  the  program, 
since  an  incorrect  entry  can  then  be  rapidly  spotted 
and  changed.  Values  could  also  be  saved  and  all 
values  printed  at  one  part  of  the  program,  which  is 
appropriate  when  the  operator  makes  a  few  entries  in 
a  long  list  of  parameters.  The  user’s  program  might 
also  save  the  operator’s  values  on  tape  for  reuse  in 
later  runs  of  the  test. 

One  major  principle  that  the  user  should  remember 
when  preparing  for  operator  inputs  is  that  it  is  more 
efficient  for  the  user  to  define  a  test  than  it  is  for  the 
operator.  The  user  is  more  familiar  with  a  test  pro¬ 
gram  and  basically  works  on  it  once;  the  operator 
works  on  it  each  time  it  is  run. 
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APPENDIX  D 

USER  SUBROUTINES 


When  preparing  a  new  test  program,  ihe  user  will 
often  want  to  write  a  new  subroutine  for  some  user- 
defined  purpose.  Also,  when  using  certain  of  the  sub¬ 
routine  blocks  (see  Table  4),  the  user  is  required  to 
provide  subroutines  with  a  predefined  purpose  of 
providing  the  next  value  for  an  output  sequence.  This 
appendix  gives  information  for  both  types.  For  con¬ 
venience,  the  appendix  is  in  two  parts:  user-defined 
and  pre-defined. 


User-Defined 

A  long  or  complicated  program  is  easier  to  read  if 
it  is  well-structured  (a  structured  program  can  be 
loosely  defined  as  one  created  by  the  combination  of 
a  number  of  nearly  independent  building  blocks,  as 
contrasted  with  a  program  in  which  every  line  is  se¬ 
quentially  determined  by  the  specific  lest  to  be 
carried  out).  The  MMG  ECM  simulator  software  has 
some  structura1  elements  in  the  subroutine  blocks. 
The  user  can  improve  a  program’s  structure  through 
intelligent  use  of  additional  subroutines,  written  by 
the  user.  A  little  structuring  effort  will  pay  off  in  a 
program  that  is  easier  to  read  and  far  easier  to  modi¬ 
fy,  and  that  can  provide  new  subroutines  for  other 
test  programs,  saving  duplication  of  effort. 

Structuring  through  subroutines  enables  the  user 
to  organize  a  test  program  as  a  main  program  and  a 
number  of  subroutines  (which  include  the  subroutine 
blocks).  The  main  program  can  then  be  basically  an 
arrangement  of  subroutine  calls.  An  advantage  of 
this  approach  is  that  it  will  make  it  easier  to  read  a 
program,  by  outlining  in  one  place  what  the  program 
does.  For  example,  consider  a  simple  case  in  which 
the  program  prompts  the  operator  through  a  list  of 
possible  inputs,  makes  a  number  of  calculations 
using  those  inputs,  and  then  sets  devices  and  runs 
patterns.  Without  subroutines,  anyone  reading  the 
program  would  have  to  read  through  all  the  input 
lines  to  find  that  the  program  does  calculations  and 
then  read  through  all  the  calculation  lines  to  find 
what  the  program  sets  and  runs.  If  more  than  a  few 
lines  are  involved,  the  reader  can  become  confused  or 
lost.  By  using  subroutines,  the  program  lets  the 
reader  grasp  the  program’s  organization  by  reading 


a  few  adjacent  lines,  showing  that  the  program  calls 
an  input  routine,  a  calculation  routine,  and,  finally,  a 
set  and  run  routine  (or .  outines). 

Such  structuring  can  be  particularly  useful  in  a 
multiple-interval  test  program  (see  Appendix  B). 
Aside  from  making  it  easier  to  follow  the  overall 
form,  a  subroutine-based  structure  would  make  it 
much  easier  to  modify  a  test  by  changing  interval 
order  or  adding  or  deleting  intervals;  the  user  would 
only  need  to  manipulate  single  instructions  (the  sub¬ 
routine  calls)  rather  than  entire  procedures  many 
lines  long. 

When  using  subroutines  to  structure  a  program, 
the  user  should  try  to  use  good  explanatory  label 
names  (see  Appendix  B).  A  number  of  studies  have 
suggested  that  human  short-term  memory  typically 
holds  six  or  seven  items.  Good  label  names  can  re¬ 
duce  the  number  of  items  a  reader  must  remember  in 
order  to  understand  a  program. 

The  six-  or  seven-item  figure  for  human  short-term 
memory  suggests  that,  when  dealing  with  a  very  com¬ 
plex  program,  the  user  should  try  to  structure  the 
program  so  that  any  one  interval  (or  other  program 
division)  could  be  understood  as  a  sum  of  six  or 
fewer  parts.  The  user  can  stack  subroutines  to  this 
end,  having  one  subroutine  call  a  number  of  others. 
The  only  limit  to  the  depth  to  which  subroutines  may 
be  stacked  on  (he  HP9825  is  the  available  memory;  if 
memory  size  does  become  a  problem,  the  user  can 
break  the  program  into  a  number  of  separately  taped 
segments  (see  Appendix  G). 

Another  advantage  to  using  subroutines  is  that 
they  can  be  used  more  readily  to  carry  out  the  same 
task  in  other  test  programs.  The  user  faced  with  a 
task  common  to  several  test  programs  could  write  a 
single  subroutine  shared  by  the  tests,  rather  than 
having  to  rewrite  the  task  instructions  for  each  test. 
The  user  could  build  up  a  library  of  subroutines  that 
join  the  subroutine  blocks  in  being  readily  available 
to  each  new  test  program,  the  new  subroutines  being 
saved  on  tape.  To  fully  exploit  this  capacity,  the  user 
should  follow  certain  rules  and  suggestions  below  on 
variable  use. 

In  the  HP9825  HPL  language,  all  variables  except 
subroutine  p-numbers  are  global.  These  global  vari¬ 
ables  may  be  read  or  assigned  values  anywhere  in  a 
program.  Local  p-numbers  are  dynamically  allocated 
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when  a  subroutine  is  called  and  are  lost  when  the  sub¬ 
routine  returns.  The  p-numbers  (p#s)  of  one  subrou¬ 
tine  are  independent  of  the  p#s  in  another  subroutine 
(save  when  one  subroutine  calls  another,  passing  p# 
parameters;  an  assignment  to  the  p#  in  the  second 
subroutine  corresponding  to  the  passed  p#  in  the  first 
subroutine  will  affect  the  value  of  the  p#  in  both  sub¬ 
routines.  See  the  HP9825  reference  manuals). 

If  a  subroutine  is  to  be  generally  useful  in  different 
test  programs,  it  should  use  p#s,  reserved  subroutine 
variables  (simple  variables  U-Z),  and  general  data 
(X(*  | ,  Z[*],  etc.;  see  Appendix  E).  This  requires 
that  all  necessary  parameters  be  passed  in  the  subrou¬ 
tine  call.  While  this  involves  more  programming 
effort  than  direct  use  of  global  variables,  it  frees  the 
subroutines  from  dependence  on  the  particular  vari¬ 
able  used.  This  in  turn  gives  the  program  calling  the 
subroutine  more  flexibility  in  using  the  global  vari¬ 
ables  and  allows  expressions  to  be  used  in  the  calls, 
l  or  example,  rather  than  writing  a  subroutine  that 
uses  the  variable  F  to  hold  a  frequency  value,  the  user 
would  use  a  pH  (such  as  p2)  for  the  frequency.  The 
subroutine  calling  program  (which  may  itself  be  a 
subroutine)  would  have  to  pass  the  value,  but  it 
would  be  free  to  use  variables  other  than  F  to  hold 
the  frequency  value  passed  and  could  also  pass  ex¬ 
pressions  or  functions,  while  F  could  be  used  for 
some  other  purpose. 

A  rule  of  thumb  for  variable  use  in  such  subroutine 
structured  programs  is  to  use  the  global  variables  in 
setting  up  parameters  passed  with  the  subroutine 
calls,  and  p#s  and  reserved  data  (see  Appendix  E)  in 
the  subroutines.  A  subroutine  should  use  a  global 
variable  other  than  the  reserved  variables  only  in 
well-defined  special  cases,  such  as  the  nextval  sub¬ 
routines  (below).  The  reserved  simple  variables  are 
particularly  used  as  for/next  loop  indices. 

Another  suggestion  for  writing  subroutines  is  to 
use  a  consistent  order  in  passing  parameters  (see  Ap¬ 
pendix  B).  It  will  make  it  easier  to  use  that  subroutine 
if  the  user  can  readily  remember  the  parameter  order 
without  having  to  look  it  up.  A  consistent  order  also 
makes  reading  and  modifying  a  subroutine  easier.  In 
this  sense,  a  consistent  order  can  be  considered  a  logi¬ 
cal  extension  of  using  good  mnemonic  label  names. 
A  rigorously  consistent  order  is  not  required  and  ex¬ 
ceptions  can  be  made,  but  the  following  can  be  taken 
as  guidelines: 

1.  In  subroutines  affecting  one  VCO  (or  all  VCOs 
in  a  band),  give  the  VCO  number  (or  band  num¬ 
ber)  first.  This  may  be  extended  to  a  case  using  a 
fixed  number  of  VCOs  not  necessarily  in  the 


same  band;  give  the  VCO  numbers  first. 

2.  In  subroutines  affecting  a  variable  number  of 
VC'Os,  give  (he  VCO  numbers  last  (use  pO  to  find 
the  number  of  VCOs  after  allowing  for  other 
passed  parameters). 

3.  Give  deviation  centers  (if  applicable)  before  devi- 
ation  magnitudes,  magnitudes  before  tales,  and 
rates  before  miscellaneous  parameters  (e.g., 
“swpl75”  passes  VCO  number,  center  fre¬ 
quency.  I M  bandwidth.  WP5  block  rate,  and 
W175  function  number,  in  that  order). 

4.  Pass  parameters  as  unit-scaled  numbers  (except 
periods,  which  are  in  milliseconds),  to  remain 
consistent  with  the  subroutine  blocks  (see 
Appendix  C). 

The  user  will  probably  appreciate  that  a  subroutine 
structure  should  make  it  easier  to  prepare  long  pro¬ 
grams  and  to  debug  and  modify  shorter  ones  as  well. 
When  preparing  a  relatively  shoit  or  simple  program, 
especially  one  prepared  on  short  notice,  the  user  may 
find  it  easier  to  use  a  straight-ahead  approach  with 
no  subroutine  structure.  This  can  be  perfectly  accept¬ 
able,  and  an  operator  generally  would  never  see  any 
difference.  If  a  short  program  is  wanted  for  a  brief 
run,  it  may  make  no  difference  to  the  user  either.  The 
user  preparing  a  test  should  ask  the  hypothetical 
question  of  whether  the  user  expects  to  modify  that 
program  later,  or  use  part  of  it  in  a  different  test,  or 
if  a  different  programmer  will  be  using  the  program 
in  some  way.  If  the  answer  is  yes,  it  could  be  more  ef¬ 
ficient  to  use  a  good  structure  from  the  beginning, 
rather  than  to  try  to  impose  one  later. 

When  actually  writing  a  user-defined  subroutine, 
there  are  fewer  specific  rules  or  suggestions  to  pass 
on,  since  the  subroutine  form  basically  depends  on 
what  the  user  wants  done.  It  has  already  been  noted 
that  the  user  is  assumed  to  be  familiar  with  the  HP1 
language  and  so  should  need  no  reminders  about 
multiple  instructions  on  a  line,  use  of  pO,  and  de¬ 
faulting  passed  p#s  to  zero  by  not  passing  them.  A 
number  of  general  suggestions  follow. 

A  user-defined  jubroutine  may  or  may  not  involve 
sending  data  over  the  bus.  The  user  should  be  able  to 
handle  most  bus-involving  data  by  using  the  subrou¬ 
tine  blocks.  When  the  user  does  wish  to  send  some¬ 
thing  over  the  bus  from  a  new  subroutine,  one  of  the 
existing  subroutine  blocks  can  serve  as  a  model  for 
the  data  formatting,  addressing,  and  tracking  (see 
Appendix  K).  It  is  expected  that  most  cases  in  which 
the  user  wants  a  new  subroutine  to  send  something 
over  the  bus  will  involve  setting  the  arbitrary  wave¬ 
form  generators  or  running  some  complicated  multi- 
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pie  VCO  ouipui  patiern.  The  former  basically  in¬ 
volves  sending  a  properly  set  up  string  to  the  right 
WI75  address  (see  Appendix  H)  and  the  latter  is  basi¬ 
cally  a  matter  of  finding  data,  formatting  it,  and 
sending  it  to  the  right  place  at  the  right  time.  In  this 
latter  case,  a  nextval  type  approach  can  be  used  (see 
below).  The  user  should  base  the  required  return 
form  on  an  estimate  of  the  highest  desired  rate  (e.g., 
if  a  run-type  output  involves  changing  tune  centers  at 
a  low  rate,  the  nextval  could  return  single  D/A  num¬ 
bers  and  could  get  those  numbers  from  frequencies 
using  “fval#”.  If  a  high  rate  will  be  needed,  the 
nextval  should  ret  urn  tune  words  taken  from  a  table 
prepared  in  advance;  see  below).  Also,  in  running 
limed  output  patterns,  the  user  should  allow  for  the 
program  instruction  time  in  setting  waits,  as  is  done 
in,  for  instance,  "stepmod.”  The  necessary  offset 
times  could  be  held  in  an  expanded  X  |  *  |  or  in  some 
other  user-selected  variable,  with  the  former  pre¬ 
ferred  when  the  user  subroutine  is  to  be  used  in  other 
programs. 

The  user  may  also  include  some  simple  value 
checks  to  ensure  that  passed  parameter  values  are 
legal  (again,  this  is  especially  appropriate  il  the  sub¬ 
routine  will  be  used  in  other  test  programs).  The  sort 
of  tests  and  the  response  to  any  error  will  depend  on 
the  expected  future  use  of  the  subroutine.  If  it  is  used 
only  in  a  specific  test,  the  subroutine  checks  may  in¬ 
volve  the  values  of  known  global  variables  in  that  test 
and  so  allow  one  subroutine  check  to  involve  know¬ 
ledge  of  other  results.  The  error  response  may  in¬ 
volve  getting  the  operator  to  fix  the  bad  condition.  A 
general  use  subroutine  should  restrict  its  checks  to 
the  passed  parameters  and  the  data  contents,  so  that 
each  subroutine's  checking  is  independent  of  others. 
The  error  response  could  not  assume  any  knowledge 
of  the  calling  program’s  structure  and  so  should  halt 
the  simulator  through  “err  sip"  (the  user  should 
make  up  a  unique  Z  code;  see  Appendix  I  ). 

To  maintain  good  structure,  each  user-written  sub¬ 
routine  should  carry  out  one  primary  task.  A  larger 
task  may  be  broken  into  subtasks  performed  by  sep¬ 
arate  subroutines.  Thus,  if  for  example  the  user 
wished  to  fill  a  number  of  r-numbers  with  values  and 
then  to  send  those  values  to  various  Rt  channels,  the 
user  would  use  one  subroutine  to  get  the  r-numbers 
and  another  to  run  the  actual  output.  This  would  im¬ 
prove  the  structure’s  clarity  and  make  it  easier  to 
change  the  nature  of  the  output  values,  by  using  a 
different  subroutine  when  getting  the  r  number 
values. 

In  all  user-written  subroutines,  the  final  choice  of 
what  'he  subroutine  does  and  how  it  does  it  is  up  to 


the  user.  It  is  up  tv'  the  user  to  decide  if  the  additional 
programming  required  by  subroutine  structuring, 
data  checks,  and  the  rest  would  be  repaid  by  case  ol 
later  use  and  modification. 

Pre-Defined 

In  contrast  to  the  user-defined  subroutines  are 
those  in  which  the  purpose  has  been  pre-defined  but 
whose  form  is  largely  up  to  the  user.  These  subrou¬ 
tines  are  termed  next  value  or  nextval  subroutines. 
An  explanation  of  their  purpose  will  show  how  the 
nextval  label  is  self-defining. 

It  was  mentioned  in  Appendix  15  that  some  run 
type  subroutines  tie  up  the  controller  in  order  to  run 
an  output  pattern,  and  it  was  mentioned  above  that  it 
can  improve  a  program’s  structure  and  make  modi¬ 
fications  easier  if  each  subroutine  performs  one  pri¬ 
mary  task.  The  run  type  subroutines  adhere  to  this 
concept.  The  basic  run  type  subroutines  (first  column 
vif  Table  4)  are  primarily  concerned  with  the  propet 
addressing  of  a  number  of  output  values  in  a  se¬ 
quence.  These  subroutines  in  turn  call  on  other  sub¬ 
routines  to  get  the  actual  .alues  output.  This  latter 
group  of  subroutines  is  called  on  each  output  step  of 
the  run  type  subroutines  to  provide  the  next  value; 
hence  as  a  class  they  can  be  called  nextval  subrou¬ 
tines. 

The  main  advantage  of  this  approach  is  that  it  en¬ 
ables  i he  user  to  specify  new  run  type  output  forms 
without  having  to  rewrite  the  controller-simulator 
address  manipulations  each  time  (indeed,  the  casual 
user  does  not  even  have  to  be  aware  of  the  internal 
addressing).  The  user  has  only  to  specify  the  nextval 
subroutine  to  specify  the  output  and  can  do  so  in  a 
number  of  ways,  giving  the  user  great  flexibility. 

This  flexible  adaptation  can  be  carried  out  as  part 
of  a  program.  For  example,  the  user  might  provide  a 
number  of  nextval  forms  and  let  the  operator  specify 
which  to  use  in  a  given  test  run.  The  user  could  also 
change  the  nextval  during  a  multi-interval  test,  so 
t hai  the  same  tun  type  subroutine  when  called  in  dif¬ 
ferent  intervals  would  result  in  different  outputs 

Nextval  subroutines  are  one  exception  to  the  gen 
eral  rule  against  using  general  global  variables  in  a 
subroutine.  Conceptually,  any  nextval  subroutine 
can  be  regarded  as  being  specific  to  the  test  in  which 
it  is  used,  so  there  is  no  portability  from  one  test  pro¬ 
gram  to  another  to  be  lost  if  the  general  global  vari¬ 
ables  (see  Appendix  E)  are  used.  Through  such  vari¬ 
ables  the  user  can  have  the  main  program  set  up  or 
modify  the  run  type  output . 
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The  calling  subroutines  must  provide  the  ad¬ 
dressing  and  basic  tinting  control  for  the  output,  as 
well  as  any  necessary  manipulation  of  the  nextval  re¬ 
turn.  The  kind  of  data  manipulation  required  de¬ 
pends  on  the  format  of  the  nextval  return,  and  this, 
in  turn,  will  be  determined  by  the  expected  maximum 
output  rate.  When  a  high  rate  is  needed,  data  manip¬ 
ulations  during  the  output  run  should  be  kept  to  a 
minimum.  If  necessary,  fully  manipulated  data  can 
be  calculated  in  advance  of  the  output  run;  and 
tabled  in  an  array  or  as  r-numbers;  the  nextval  would 
then  be  concerned  with  finding  the  right  table 
entry. 

The  user  must  pay  certain  attention  to  the  output 
liming  when  writing  a  nextval  subroutine.  Any  run 
type  output  implies  that  the  controller  sets  the  output 
rate  by  controlling  the  time  any  one  output  value  re¬ 
mains  set  (the  dwell  time).  Typically  the  dwell  time  is 
implied  by  a  passed  rate,  but  it  may  itself  be  a  nextval 
return  (e.g.,  "stepmod").  In  setting  up  a  wait  in¬ 
struction  to  match  the  desired  dwell,  allowance 
should  be  made  for  the  time  required  by  the  actual 
output  instructions  (the  loop  time).  This  is  done  by 
off  setting  the  dwell  time  by  the  loop  time  to  get  the 
wait  time.  For  example,  if  a  desired  dwell  is  40  ms 
(corresponding  to  a  25  Hz  output  rale)  and  the  out¬ 
put  instructions  take  35  ms  to  complete,  the  actual 
wait  time  would  be  40-35,  or  5  ms. 

The  user  will  appreciate  that  the  loop  time  repre¬ 
sents  the  minimum  actual  dwell,  corresponding  to  a 
wait  of  zero,  and  hence  that  the  loop  time  sets  the 
maximum  output  rate.  Some  of  the  instructions  in  an 
output  loop  are  essential:  the  output  loop  control, 
the  nextval  call,  the  output  write  over  the  bus  to  the 
multiprogrammer,  and  the  check  to  allow  the  multi¬ 
programmer  to  handle  one  output  before  sending  the 
next  (see  the  description  of  “?”,  Appendix  O;  an 
analog  would  apply  if  the  output  loop  did  not  involve 
the  multiprogrammer  but  involved  some  other  bus 
device).  The  time  required  for  these  instructions  sets 
a  minimum  dwell  time  restriction  on  the  controller. 
On  the  HP9825  this  time  is  about  35  ms,  corre¬ 
sponding  to  a  maximum  rate  of  about  28  Hz. 

A  run  type  subroutine  could  generally  be  written  so 
as  to  allow  the  maximum  output  rate;  this  can  be 
done  by  requiring  that  at  least  some  of  any  needed 
data  manipulations  be  carried  out  outside  the  calling 
subroutine.  For  example,  a  run  type  subroutine  that 
sets  new  tune  center  frequencies  could  require  that  its 
nextval  subroutine  return  the  D/A  number  to  be  set. 
The  nextval  subroutine  could  get  the  D/A  number 
from  the  next  frequency  value  or  it  could  look  up  a 
table  of  D/A  numbers  prepared  in  advance.  How  the 


nextval  gets  the  D/A  number  would  make  no  differ¬ 
ence  to  the  calling  subroutine,  with  one  exception. 

Since  the  essential  instructions  in  any  run  type  out¬ 
put  loop  include  getting  the  next  value,  the  loop  time 
must  reflect  the  time  needed  to  get  the  value.  If  there 
are  two  alternate  nextvals  for  a  calling  subroutine 
one  simple  (say,  a  D/A  number  table  lookup)  and  the 
other  complex  (say,  a  calculated  frequency  converted 
through  “fval#“  to  a  D/A  number),  then  the  loop 
times  can  differ  significantly  and  the  dwell  offset 
must  be  adjusted  to  fit  the  nextval  used. 

In  order  to  allow  for  this,  the  loop  time  should  be 
represented  in  the  calling  subroutine  by  a  known  data 
variable.  If  the  loop  time  is  then  changed  by  changing 
the  form  of  the  nextval,  the  value  of  that  variable  can 
be  adjusted.  The  subroutine  blocks  use  entries  in  X 
|‘  ]  to  hold  loop  times.  The  user  writing  new  run 
type/nextval  subroutines  can  expand  X  |  ‘  |  to  hold 
the  new  values,  or  could  assign  some  other  data 
variable  for  the  same  purpose. 

Loop  times  can  be  estimated  after  a  little  practice 
or  measured  as  the  difference  between  a  known  wail 
time  set  in  the  program  and  the  observed  actual  dwell 
time.  Such  differences  are  easier  to  measure  at  low 
rates  than  high  ones.  It  can  also  be  easier  and  more 
accurate  to  measure  actual  dwells  by  observing  volt¬ 
age  changes  inside  an  ri  channel  using  an  oscillo¬ 
scope  (especially  one  with  storage  capability)  than  by 
observing  Rt  output  changes  on  a  spectrum  analyzer, 
though  the  latter  is  easier  to  hook  up. 

Additional  instructions  besides  the  essential  ones 
may  be  part  of  the  calling  subroutines  (or  the  next¬ 
vals),  such  as  data  checks  and  manipulations.  While 
data  manipulations  as  part  of  a  calling  subroutine 
will  reduce  the  maximum  output  rate,  they  also  make 
it  easier  to  write  the  nextval,  an  advantage  if  a  casual 
user  prepares  a  nextval  because  it  requires  less 
detailed  knowledge  and  less  effort. 

The  number  of  individual  outputs  during  a  run 
type  pattern  is  directly  or  indirectly  controlled  when 
the  main  program  calls  the  calling  subroutine  (see 
Appendix  B).  Typically  this  is  done  by  setting  up  a 
for/ next  loop  in  the  calling  program,  using  a  reserved 
simple  variable  (i.e.,  X)  as  the  index.  The  nextval 
may  read  the  index  value  if  the  user  so  wishes  (but 
should  not  change  that  value).  The  tie-up  time  is  the 
sum  over  the  number  of  individual  outputs  of  the  in¬ 
dividual  dwells  (the  dwells  may  vary  if  the  output  rate 
is  not  fixed).  The  run  type  subroutines  set  the  number 
of  outputs  in  the  for/next  loop,  with  dwells  set  either 
fixed  by  the  rate  (e.g.,  “AMown")  or  by  a  nextval 
return  (e.g.,  “stepmod”). 
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The  remainder  of  this  appendix  describes  three 
subroutine  blocks  t hat  require  the  user  to  provide 
nextval  subroutines:  “AMown,”  "stcpmod,” 
and  "special."  The  user  will  find  that  a  numbet  of 
details  below  can  be  readily  adapted  to  new  run  type 
subroutines. 

The  subroutine  block  "AMown”  shows  how  lo 
use  the  digital  output  cards  in  the  HP6943  extender 
to  get  an  AM  signal  (a  directly  analogous  subioutine 
could  be  written  to  use  the  f  M  card).  The  subroutine 
was  originally  wtitten  before  a  second  W175  wave¬ 
form  generator  was  added  to  the  simulator  as  an  am 
source.  The  subroutine  remains  useful  since  it  pro¬ 
vides  a  way  of  getting  AM  if  the  second  VV  175  is  pre¬ 
empted  for  use  as  a  pulse  source.  The  subroutine  also 
has  a  larger  valid  range  than  does  the  VVI75  (see 
Appendix  H). 

“AMown”  is  called  with  a  fixed  rate  and  a  speci¬ 
fied  number  of  output  steps  The  rate  is  given  as  the 
number  of  steps  per  second  (see  Appendix  O).  The 
required  nextval  subroutine  is  "AMval  " 
"AMval”  has  the  VCO  number  passed  as  pi  and 
may  read  the  output  loop  index  (the  output  step 
number)  in  X.  The  nextval  must  return  a  value 
tepresenting  decibels  of  attenuation  relative  to  the 
current  output  power  level.  The  decibel  value  is 
returned  by  assigning  it  to  the  variable  U;  its  usual 
range  is  0-55  dB. 

A  simple  example  of  an  ”AMval”  form  can  be 
used  as  a  default  that  will  result  in  a  sine  squared 
output: 

"AMval":  30 1  sin  (X)  12  |  -U;  ret. 

The  main  program  should  have  set  radian  angular 
units.  In  place  of  the  fixed  maximum  of  30  dB,  the 
user  could  use  any  available  simple  variable,  assigned 
a  value  before  "AMown”  is  called,  or  perhaps  an 
array  using  the  passed  VC'O  number  in  pi  as  the  array 
index. 

The  "stepmod"  subroutine  is  called  with  the 
number  of  output  points.  The  subroutine  allows  an 
arbitrary  frequency  pattern  to  be  run  through  the 
controller.  Each  output  point  requires  a  tunc  card 
D/A  number  from  the  nextval  "stepval”  and  a 
dwell  time  at  the  resulting  frequency  from  the  nextval 
“stepwt".  The  loop  index  is  in  X  and  both  nextvals 
are  passed  the  VCO  number. 

The  nextval  "stepval”  returns  a  D/A  number 
through  U.  Any  integral  number  0-255  will  be  ac¬ 
cepted  by  “stepmod;”  it  is  up  to  the  user  to  ensure 
h.ii  l.c  result  is  meaningful.  The  nextval  "stepval” 


could  calculate  a  frequency  by  some  algorithm,  check 
that  the  frequency  is  legal,  and  use  "fval  #”  to  get 
the  D/A  number.  It  could  also  get  the  D/A  number 
directly,  including  implicit  checks  in  the  way  it  gets 
the  next  value.  As  an  example,  suppose  the  user 
wanted  to  hop  the  tune  center  randomly  between  two 
frequency  limits.  The  main  program  could  use  "fval 
#"  and  the  min  and  max  functions  to  get  the  lower 
D  A  number  limit  in  L  and  the  difference  with  the 
higher  D/A  number  limit  in  D  (the  low  D/A  number 
does  not  necessarily  correspond  to  the  low  fre¬ 
quency).  The  nextval  would  be: 

“stepval”:  L  +  int(Drnd(l))  —  U. 

The  nextval  "stepwt"  returns  a  dwell  time 
thiough  U.  Its  range  depends  on  the  loop  time  value 
in  X  1 2  ]  but  should  typically  be  about  40  to  32,807 
ms.  The  user  can  use  a  fixed  dwell  or  one  that  is  fixed 
for  a  number  of  output  steps  (or  an  amount  of 
overall  time)  and  then  changes,  or  one  that  varies  on 
every  output  step.  A  simple  example  for  a  fixed  rate 
might  assume  that  the  main  program  has  put  a  rate 
value  in  steps/s  or  Hz  in  the  variable  R: 

"stepwt":  le.3/'R  — U;  ret. 

The  "special' ‘subroutine  is  called  using  rate  and 
running  time.  It  is  used  to  synchronously  hop  all 
three  VCOs  in  a  band.  The  subroutine  was  written  to 
allow  for  high  oupul  rates,  with  a  measured  maxi¬ 
mum  of  about  26.3  Hz.  To  get  the  higher  rates,  the 
output  values  must  be  calculated  and  tabled  in 
advance.  The  table  length  parameter  is  passed  to 
specify  how  long  the  table  is  and  hence  how  many 
entries  to  read  before  repeating  the  table. 

The  r-numbers  are  usually  used  to  hold  the  data, 
rather  than  an  array,  since  the  r-numbers  do  not  need 
to  be  dimensioned  (this  makes  it  easier  to  vary  the 
table  length).  The  passed  table  length  does  not  have 
to  be  the  full  table  length;  by  using  only  part  of  the 
table,  the  user  can  examine  the  effect  of  the  nonran¬ 
dom  repeating  of  table  values.  The  length  of  the  table 
should  ideally  be  as  long  as  possible;  the  user  may  use 
this  subroutine  as  a  separately  taped  segment  so  as  to 
eliminate  other  parts  of  the  program  and  so  allow 
more  data  space.  A  string  array  is  not  suitable  for 
holding  “special"  values;  at  high  rates  it  would 
take  too  long  to  convert  the  string  to  numeric 
form. 

The  subroutine  needs  five  values  on  each  output 
step.  Two  of  these  represent  the  three  tune  center 
values  and  three  represent  the  rf  channel  function 
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control  words.  By  sending  the  latter  out  on  each  out¬ 
put  step,  the  subroutine  allows  a  number  of  special 
moves:  noise  spots  can  be  kept  constant  even  as  the 
tune  centers  change;  the  noise  spots  can  be  varied 
after  a  certain  amount  of  time;  and  the  carriers  can 
be  turned  off  to  simulate  a  look-through.  The 
channel  control  words  could  also  be  left  alone  for  a 
simple,  easier  to  program  version  of  the  output 
pattern. 

The  nextval  subroutine  “valspec”  must  return 
the  required  data  in  specified  variables,  as  follows: 

U  -  double  tune  word, 

W  -  single  tune  word, 

Y  -  channel  control  word.  A, 

Z  -  channel  control  word,  B,  and 

V  -  channel  control  word,  C. 

The  three  VCOs  in  a  band  can  here  be  given  the  labels 
A,  B,  and  C,  in  order  of  increasing  VCO  number 
(these  labels  are  not  related  to  the  VCO  A  or  B  indi¬ 
cated  on  the  front  panel  of  the  simulator).  The  data 
returned  from  "valspec”  is  passed  on  to  the  multi¬ 
programmer  without  any  checks  or  manipulations. 
As  a  result,  the  tune  data  must  be  already  formatted, 
making  this  the  most  difficult  nextval  for  the  user  to 
prepare  (an  easier  way  of  getting  hopping  can  be 
written,  but  the  maximum  rate  is  only  about  12.3 
Hz). 

The  data  for  this  nextval  must  be  prepared  in  ad¬ 
vance.  For  each  output  step,  the  user  must  have  three 
D/A  numbers  which  may  be  found  by  calculating  a 
frequency  and  finding  the  D/A  number  or  by  directly 
getting  a  D/A  number  (this  part  is  strongly  similar  to 
the  "stepmod”  nextval  “stepval”).  The  numbers 
are  then  shifted  as  necessary,  so  that  a  D/A  number 
for  the  high  end  of  a  tune  card  is  shifted  eight 
positions  and  one  for  the  low  end  is  unshifted 
(shifted  0).  Two  of  the  numbers  must  then  be  put  to¬ 
gether  as  one  word  (using  inclusive  OR). 

To  remember  which  VCOs  are  put  together,  the 
user  need  only  note  if  the  VCOs  are  in  the  lower 
bands  (a  type  I  rf  channel,  bands  B  and  C)  or  the 
higher  bands  (a  type  II  rf  channel,  bands  D  and 
E/F).  Using  the  VCO  A,  B,  C  notation  mentioned 
above,  the  necessary  shifts  and  inclusive  OR’s  are  in¬ 
dicated,  using  (s)  to  indicate  a  high  end  shift  and  /  to 
indicate  two  numbers  put  together: 

low  band:  A/B(s),C, 

high  band:  A(s),  B/C(s). 

If  the  rf  channel  function  control  words  are  to  be 
actively  changed  during  a  “special”  run,  data 
values  must  be  set  up  for  (hem.  This  can  be  done  by 
using  the  appropriate  Z  [  *  ] entries  as  a  basis.  The 


Z 1  *  ]  locations  can  be  found  from  the  band  number 
in  a  manner  analogous  to  that  used  in  the  second  line 
of  "special.”  The  VCO  select,  pulse  and  biphase 
carriers,  and  initial  noise  spots  can  be  set,  giving 
2[']a  set  of  initial  values  (if  necessary,  the  power 
level  can  be  kept  at  81  dB  down  to  keep  any  output 
from  appearing  while  the  data  are  set  up).  Then,  for 
each  noise  spot  (or  other)  change,  the  appropriate 
subroutine  “fnoise”  (or  “pulse”  and  "biph”  to 
turn  carriers  on/off  for  look-through)  is  called,  after 
which  the  Z  [  * ) contents  are  saved.  The  process  could 
be  continued  for  each  output  change. 

If  a  simpler  approach  is  used  and  the  rf  channel 
function  control  words  remain  fixed  for  the  test  run, 
then  the  user  can  make  a  single  direct  assignment 
from  the  appropriate  Z  [*  ]  locations  to  the  variables 

Y, Z,  andV. 

The  nextval  subroutine  itself  would  basically  be 
concerned  with  finding  the  right  table  entry  for  each 
variable  on  each  output  step.  The  step  number  or 
loop  index  can  be  read  in  X  and  the  table  size  is 
passed  as  pi.  Typically  the  nextval  would  use  the  step 
number  in  X  to  find  a  basic  table  location  and  would 
count  a  fixed  number  of  entries  past  that  basic  loca¬ 
tion  to  get  all  the  variables  for  that  step,  while  the 
table  length  is  used  to  fold  around  the  end  of  the 
table  and  so  repeat.  The  table  length  should  be  some 
integral  multiple  of  the  number  of  entries  used  at 
each  step  (the  for/next  loop  set  up  in  "special”  may 
need  to  be  modified  to  reflect  the  number  of 
variables  used  on  each  step). 

As  an  example  for  “valspec,”  suppose  we  have 
the  simple  case  in  which  the  channel  control  words 
remain  fixed.  In  this  case  the  main  program  would 
directly  assign  the  appropriate  contents  of  Z  [  *  ]  to  Y, 

Z,  and  V  (after  setting  the  VCO  select,  carriers,  and 
noise).  The  r-numbers  would  contain  the  tune  words, 
prepared  before  the  "special”  call.  The  numbers 
could  be  prepared  as  part  of  the  program  or  in  ad¬ 
vance  and  saved  on  tape.  The  double  word  would  be 
held  in  the  even-numbered  entries  and  the  single 
words  in  the  odd-numbered  entries.  The  example  for 
“valspec”  would  then  be: 

“valspec”:  r(X  mod  pi)  — U 

r[(X+  l)mod pi]  — W;  ret. 

There  is  an  obvious  extension  of  this  to  cover  the 
case  when  the  channel  control  words  do  change,  or 
those  words  could  be  held  in  a  separate  array  or  by 
rearranging  the  r-numbers  to  hold  contiguous  groups 
of  the  same  variables  (i.e.,  all  values  for  U  followed 
by  all  values  for  W,  etc.).  It  is  up  to  the  user  to  decide 
what  nextval  form  is  needed  for  a  particular  test. 
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APPENDIX  E 

DATA  AND  VARIABLES 


This  appendix  describes  the  data  and  variables 
used  by  the  subroutine  blocks.  As  has  been  men¬ 
tioned  in  Appendix  D,  the  subroutine  blocks  chiefly 
use  local  p-numbers  as  the  internal  variables.  Global 
variables  are  used  as  for/next  loop  indices,  to  hold 
data,  set  up  output  strings,  handle  some  value  pas¬ 
sing  (between  a  run  type  subroutine  and  an  associ¬ 
ated  nextval  subroutine;  see  Appendix  D),  and  han¬ 
dle  error  messages. 

The  user  may  freely  use  all  global  variables  not  re¬ 
served  by  the  subroutine  blocks  and  may  use  all  of 
the  free-use  flags  (flags  0-12).  The  user  may  also  read 
the  data  values  held  in  the  reserved  variables.  Table 
E-l  contains  a  guide  to  user  assignments  involving 
the  reserved  variables;  a  rule  of  thumb  might  be  for 
the  user  to  avoid  reserved  variable  assignments  ex¬ 
cept  for  using  U$  in  handling  operator  inputs.  Tor 
reference,  the  reserved  variables  are: 
strings:  US,  VS,  W$,  X$,  Y$,  Z$. 
arrays:  X  |  *  ] ,  Z  |  * ) , 
simple:  U,V,  W,  X,  Y,  Z. 

Data  are  used  by  the  subroutine  blocks  chiefly  to 
determine  what  values  are  sent  over  the  bus  in  order 
to  get  a  desired  output.  The  main  bus  messages  are 
directed  to  the  tune  and  channel  function  control 
cards  in  the  multiprogrammer.  Proper  output  word 
manipulations  using  the  subroutine  blocks  require 

Table  E-1  -  User  assignment  of  reserved  variables. 


l  aruihte 

Assignment  Rule 

Z% 

Never 

XS,  Y$,  W$ 

Never  (update  using  "load-S"  sub¬ 
routines) 

zn 

Extreme  caution 

xri 

Caution 

Simple  variables 
(U-Z).  v$ 

Assigned  values/contents  will  be 
overwritten  by  some  subroutine 
blocks 

US 

Use  for  inputs  ("enter").  Assigned 
contents  will  be  overwritten  by 
some  subroutine  blocks 

changes  to  the  normal  (wake-up)  slate  of  the  control¬ 
ler  and  of  the  multiprogrammer.  The  changes  are 
related  to  the  data  forms  that  enable  the  subroutine 
blocks  to  work  independently  (see  below)  and  some¬ 
what  complicate  use  of  the  controller's  flag  14. 

The  controller  wakes  up  with  its  binary  operations 
(shift,  inclusive  OR,  etc.)  in  2’s  complement  mode. 
This  complicates  control  of  the  operand  word's 
most  significant  bit  (bit  15).  which  is  needed  in  set¬ 
ting  tune  and  function  control  card  values.  I'he 
shortest  and  easiest  solution  is  to  have  the  control¬ 
ler’s  binary  operations  carried  out  with  flag  14  set. 
which  sets  the  format  to  unsigned  binary. 

On  paper,  the  binary  operation  result  could  then 
be  sent  to  the  multiprogrammer,  in  which  the  digital 
output  cards  wake  up  in  unsigned  binary  format.  In 
practice,  it  was  found  that  this  would  result  in  a  tnult- 
iprogrammer  error  when  the  word  sent  has  bit  15  set 
(regardless  of  whether  flag  14  was  still  set  or  not  at 
the  time  the  word  was  sent).  The  multiprogrammer  in 
its  wake-up  mode  will  accept  a  decimal  value  word 
with  bit  15  set  (e  g.,  65510)  if  that  word  is  sent  as  a 
literal  but  not  if  the  word  is  formed  through  the  con¬ 
troller’s  binary  operations.  It  seems  as  if,  while  the 
controller  will  allow  a  word  to  be  formed  as  an  un¬ 
signed  binary  number  when  flag  14  is  set,  that  word 
will  be  passed  to  the  multiprogrammer  as  if  it  were  a 
negative  number  when  bit  15  is  set  (i.e,  it  seems  to  go 
back  to  2’s  complement  regardless  of  Hag  14)  and 
the  multiprogrammer  cards  will  refuse  to  accept  that 
word  as  an  unsigned  binary  pattern,  but  will  treat  the 
word  as  an  illegal  negative  number. 

It  was  found  that  a  proper  and  acceptable  data 
transfer  between  the  controller  and  the  multipro¬ 
grammer  can  be  made  if  the  appropriate  multipro¬ 
grammer  digital  output  cards  are  put  in  2’s  comple¬ 
ment  format.  The  cards  in  slots  2  through  12  (which 
handle  the  tune  and  channel  function  control  words, 
and  the  auxiliary  switches  and  level  set  attenuators) 
are  put  in  2’s  complement  by  the  “initial"  subrou¬ 
tine  block. 

A  straightforward  way  of  setting  flag  14  to  change 
the  controller’s  binary  operation  format  would  be  to 
sei  it  just  once,  in  “initial,”  so  that  flag  14  would 
always  be  set  in  a  program.  However,  when  flag  14  is 
set,  the  controller  also  sets  a  number  of  defaults  for 
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illegal  math  operations,  such  as  division  by  zero,  so 
that  illegal  math  operations  will  not  halt  the  pro¬ 
gram.  This  could  give  the  user  and  operator  a  false 
idea  of  what  the  simulator  is  doing. 

In  order  to  avoid  this,  flag  14  is  not  set  by  “ini¬ 
tial”  but  by  the  subroutine  blocks  that  require  the 
flag  to  be  set.  The  flag  is  set  only  when  it  is  needed 
and  will  not  lead  to  unintentional  math  defaults.  The 
subroutine  blocks  using  flag  14  will  clear  the  flag  be¬ 
fore  they  reach  their  return  statements.  It  is  impor¬ 
tant  that  the  user  remember  this  if  the  user  does  want 
flag  14  set  outside  of  the  subroutine  blocks.  In  such  a 
case,  the  user  has  two  options:  The  user  can  simply 
set  flag  14  repeatedly,  either  whenever  it  is  needed  or 
after  calling  any  subroutine  block  that  used  the  flag, 
or  the  user  can  set  flag  14  once  and  modify  the  sub¬ 
routine  blocks  by  removing  the  clear  flag  14  instruc¬ 
tions.  The  latter  is  more  appropriate  when  the  sub¬ 
routine  blocks  are  taped  as  part  of  the  test  program 
and  the  user  is  cautioned  not  to  later  mistake  the 
modified  subroutine  blocks  for  the  unmodified  ones. 
As  for  identifying  which  subroutine  blocks  use  flag 
14,  a  rule  of  thumb  is  that  any  subroutine  block  that 
sends  data  over  the  bus  will  directly  or  indirectly  use 
the  flag  (the  short  descriptions  in  Appendix  O  will 
mention  if  the  subroutine  does  not  use  the  flag; 
otherwise  the  flag  is  used). 

The  controller  data  form  all'  \  independent 
setting  of  the  simulator  devices.  1  he  Z(')  array  is 
used  for  this  purpose.  This  array  holds  replicas  of  the 
multiprogrammer  card  words;  i.e.,  Z[10]  contains 
the  word  sent  to  the  multiprogrammer  card  in  slot  10 
(see  Table  E-2).  When  a  subroutine  block  is  called  on 
to  modify  some  simulator  device  controlled  by  part 
of  a  card  word,  it  will  modify  the  appropriate  part  of 
the  right  entry  in  Z  [  *  ]  and  then  send  the  new  Z  [  *  ] 
word  to  the  card.  The  subroutine  block  does  not  have 
to  track  or  reset  the  other  devices  controlled  by  the 
same  card.  For  example,  the  biphase  circuit  of  an  rf 
channel  is  controlled  by  bits  12-14  of  the  channel's 
function  control  card;  these  bits  can  be  set  by 
"biph”  without  any  explicit  reference  to  the  VCO 
select,  pulse,  or  noise  settings. 

Z  [  *  1  is  dimensioned  and  used  in  preference  to 
some  other  approach  since  it  allows  a  good  combina¬ 
tion  of  speed,  data  tracking,  and  memory  efficiency. 
By  keeping  replicas  of  the  card  words  in  the  control¬ 
ler,  the  subroutine  blocks  do  not  need  to  read  back 
the  card  words  every  time  they  are  to  be  changed.  In 
case  of  an  error  shutdown,  the  simulator  outputs  can 
be  removed  by  sending  the  appropriate  data  to  the 
cards  while  keeping  the  previous  card  values  intact  in 


Table  E-2  -  Z|  *  1  contents. 

No.  Z\  * )  Contents  (HP6942/3  Card  Words ) 

1  Memory  card  word 

2  Tune  word,  RF  1  and  2 

3  Tune  word,  RF  3  and  4 

4  Tune  word,  RF  5  and  6 

5  Channel  function  control  word,  RF  #1 

6  Channel  function  control  word,  RF  #2 

7  Channel  function  control  word,  RF  #3 

8  Channel  function  control  word,  RF  #4 

9  Channel  function  control  word,  Rl  #5 

10  Channel  function  control  word.  RF  #6 

11  Power  amplitude  level  set 

12  Aux.  FM/aux.  AM  switch  matrices 

13  T/P  card,  overall  pulse  width 

14  Counter  card  word 

15  D/AAM,  RI  #1 

16  D/A  AM.  RF  #2 

17  D/AAM.  RF  *3 

■  8  DAA  AM,  RF  #4 

19  D/A  AM.  RF  #5 

20  D/AAM,RF#6 

21  D/A  FM 

22  Digital  input  card  word 

Z  [  * ) .  The  Z  [  *  ]  contents  could  be  used  in  debugging 
the  crash,  and  the  output  could  be  restored  by  simply 
sending  the  Z  [ * )  contents  back  to  the  cards.  The 
card  word  approach  itself  is  more  efficient  (and 
easier  to  follow)  than  direct  setting  of  individual 
bits. 
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Z|*|  niusi  be  dimensioned  before  initialization 
but  does  not  need  to  be  loaded  with  data  as  "ini¬ 
tial”  and  t he  subroutine  blocks  will  handle  the  con¬ 
tents  set  up.  An  exception  is  that  the  user  mas  on  oc¬ 
casion  want  to  assign  a  stable  nonzero  decibel  ot  at¬ 
tenuation  value  to  the  am  D&A  cards  in  slots  1 00- f  05 
(normally  the  level  set  attenuators  would  be  used  to 
uet  such  a  result,  and  ii  is  doubiful  if  a  power  attenu¬ 
ation  greater  than  the  81  dB  to  be  had  from  the  level 
set  attenuators  has  any  real  meaning). 

Within  a  subroutine  block,  the  binary  AND  opera¬ 
tion  (band)  is  used  to  mask  out  the  unaffected  part  of 
a  card  word  while  clearing  the  affected  part,  shift 
(shf)  is  used  to  line  up  the  new  value  in  the  proper  bit 
positions,  and  inclusive  OR  (ior)  combines  the 
shifted  new  value  with  the  other  card  word  contents. 
The  result  is  saved  in  Z  [  *  j  as '  he  new  card  word. 

The  run  type  subroutine  blocks  differ  slightly  in 
that  the  new  card  word  formed  on  each  output  step  is 
not  saved  in  Z  ( *  | ,  saving  a  little  on  loop  time  (band, 
shf,  and  ior  are  otherwise  used  as  in  the  previous  par¬ 
agraph).  W  hen  a  run  type  subroutine  completes  its 
run,  it  will  (except  for  “special”)  send  out  the  pre¬ 
run  7.  \  *  1  contents,  restoring  the  original  output. 

The  reserved  variables  other  than  Z  |  *  |  are  used  to 
handle  calibration  data,  controller-tape  and  eomrol- 
ler-W'175  waveform  generator  transfers,  inputs,  for/ 
next  loop  indices,  nextval  returns,  and  error  mes¬ 
sages.  These  uses  are  discussed  below  according  to 
the  variable  used. 

Z$  1 12,54]  holds  the  complete  tune  frequency  cali¬ 
bration  data  for  the  simulator.  Hash  numbered  string 
in  the  string  array  contains  the  data  for  the  VCO  with 
the  same  number  ( i , c . ,  Z$  [ 8  )  for  VCO  number  8, 
etc.).  Each  string  is  organized  as  six  sets  of  nine  char¬ 
acters,  each  set  defining  one  point  of  the  frequency- 
D/A  number  calibration  curve,  the  nine  characters 
of  each  set  are  organized  as  five  frequency  characters 
followed  bv  four  D/ A  number  characters. 

The  trings  are  arranged  so  that  the  tabled  fre¬ 
quency  increases  as  the  string  index  increases.  The 
D/A  numbers  may  be  increasing  or  decreasing.  The 
lowest  and  highest  (first  and  last)  tabled  frequencies 
are  taken  by  "fval#”  as  the  limits  for  legal  fre¬ 
quencies  from  that  VCO  number.  Unlike  the 
frequency  checks  based  on  a  band  number  calculated 
from  the  VCO  number,  this  check  is  independent  of 
the  actual  arrangement  of  VCOs  in  the  simulator 
rack  and  depends  only  on  the  data  put  in  ZS.  The  Z$ 
data  limits  could  also  be  set  to  represent  the  real- 
world  limits  of  each  VCO  tuning  curve  rather  than 
the  paper  specifications. 


Frequencies  are  tabled  in  ZS  as  fractional  number' 
in  gigahertz  units  ("fval#”  will  scale  the  number 
taken  from  the  table  to  hertz  units).  With  the  leading 
character  space  blank  la  testiit  of  forming  z'.S  with 
the  controller's  numeric-string  conversion  opera¬ 
tions),  there  are  four  significant  frequency  char 
acters.  including  any  decimal  point.  For  example, 
250  MHz  is  tabled  as  0  25  with  a  leading  blank  ')  \ 
numbers  are  tabled  as  integers  in  the  lange  0-255. 
The  D/A  number  used  is  found  by  linear  interpola¬ 
tion  from  the  tabled  data. 

ZS  is  loaded  after  dimensioning,  lfom  file  2  on 
track  1  of  a  standard  tape.  Once  loaded,  it  need'  no 
updates  during  a  test  run.  The  user  may  read  value' 
from  ZS  but  should  never  assign  to  it  because  ilia1 
would  overw  rite  the  data  contents. 

XS  16,120]  and  VS  (6. 120]  hold  noise  generatot 
and  fill  oscillator  calibration  data,  respectively.  To 
save  memory  space,  only  partial  data  sets  are  held  in 
the  controller  at  any  one  time  Each  individual  string 
contains  data  for  the  active  VCO  in  the  Kt  channel  of 
the  same  number  (i.e..  YS]4|  for  Kt  channel  number 
4.  etc.).  XS  is  further  constrained  in  that  the  data 
contained  are  also  those  for  t he  video  bandwidth  in 
current  use. 

The  noise  calibration  (noise  generator  and  fill 
oscillator)  is  organized  on  hold  points  on  the  band¬ 
width-attenuator  setting  calibration  curves.  I  he  at¬ 
tenuator  setting  (from  0,  no  attenuation,  to  full  at¬ 
tenuation)  is  implicit  in  the  position  in  the  string  ot 
the  corresponding  bandwidth  value.  I  he  bandwidth 
that  results  from  a  given  attenuator  setting  will  varv 
with  the  band  position  of  the  tune  center  about  which 
the  bandwidth  is  measured.  The  noise  data  are  cali¬ 
brated  at  three  positions  throughout  each  VCOs  fre¬ 
quency  band  to  get  data  for  low,  mid,  and  high  fre¬ 
quencies.  The  tune  center  determines  the  part  of  the 
band  in  use  and  hence  which  set  of  data  should  be 
used.  This  information  can  be  indicated  by  a  band 
part  number:  0  for  low  band,  1  for  mid  band,  and  2 
for  high  band.  Each  band  part  covers  one-third  of 
the  VCOs  band.  The  band  pan  is  used  as  an  index 
offset  in  finding  the  right  part  of  XS  or  VS. 

The  individual  strings  of  XS  and  VS  are  organized 
as  three  sets  of  40  characters.  Each  set  contains  the 
data  for  one  band  part,  with  increasing  string  index 
corresponding  to  increasing  band  part  (increasing 
frequency).  Each  set  is  organized  as  eight  groups  of 
five  characters.  The  characters  contain  the  band¬ 
width  values  in  order  of  increasing  attenuation.  The 
attenuator  setting  used  is  found  by  finding  the  closest 
tabled  frequency  to  the  desired  frequency. 
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Frequency  values  in  X$  and  Y$  are  similar  to  those 
in  Z$  except  that  the  noise  bandwidths  are  tabled  in 
megahertz  units  ("fnoise”  will  scale  the  numbers 
taken  from  the  stings  to  hertz  units).  All  tabled  band- 
widths  should  be  measured  by  the  same  standards, 
i.e..  10  dB  down  from  peak  (any  other  dB  down  level 
could  be  used  as  long  as  its  use  is  consistent). 

X$  and  Y$  can  be  loaded  after  dimensioning  from 
files  6  and  5  on  track  1  of  a  standard  tape.  When 
loaded  from  those  files,  the  noise  strings  will  contain 
data  for  the  B  labeled  VCOs  in  each  rf  channel  (i.e., 
the  higher  frequency  VCO  in  each  head),  with  X$ 
containing  the  data  for  the  5  MHz  video  noise  band¬ 
width  (video  number  5;  see  Table  E-3).  During  a 
program,  the  user  may  change  the  string  contents  to 
reflect  a  change  of  the  active  VCO  in  an  rf  channel 
or  a  change  in  the  video  filter  by  using  “loadXS” 
and' or  “loadYS.” 

It  should  be  noted  that  the  current  subroutine 
block  software  does  not  track  which  set  of  data  is  act¬ 
ually  in  X$  and  Y$.  It  is  up  to  the  user  to  do  this  and 
to  make  any  necessary  “load$”  calls.  If  “fnoise” 
is  called  with  incorrect  data  in  XS  or  YS,  those 
incorrect  data  will  be  used,  giving  erroneous  results. 
It  should  also  be  noted  that  calling  “fnoise”  with  a 
video  number  of  zero,  which  turns  off  the  noise 
generator  and  leaves  the  fill  oscillator  on,  does  not 
actually  involve  any  use  of  X$.  Thus,  a  video  number 
change  involving  a  video  number  of  zero  does  not 
require  the  user  to  update  XS  and  can  be  effectively 
ignored  (i.e.,  going  from  a  video  number  5  to  video 
number  0  to  video  number  5  is  effectively  no  change 
as  far  as  the  contents  of  X$  are  concerned;  going 
from  video  number  5  to  video  number  0  to  video 
number  4  is  effectively  going  from  number  5  to 
number  4  and  does  require  a  change  in  the  XS 
contents). 

The  user  may  read  values  from  XS  or  Y$  but 
should  never  assign  to  them. 

W$  1 6, 120 1  holds  WI75  arbitrary  waveform  gener¬ 
ator  FM  calibration  data.  Its  organization  and  use  are 
similar  to  those  of  YS,  except  that  the  string  positions 
of  the  bandwidth  values  correspond  to  WI75  volt¬ 
ages.  The  voltage  that  corresponds  to  a  particular 
bandwidth  entry  is  found  from  the  bandwidth’s 
position  and  conversion  factors  found  in  X(*  |  (see 
Table  E-4).  The  voltage  samples  are  equally  spaced. 
The  voltage  sent  to  the  fm  WI75  is  determined  by 
linear  interpolation  from  the  tabled  data. 

The  contents  of  W$  may  be  updated  using 
“loadWS”  when  the  active  VCO  in  an  rf  channel 


Table  E-3  -  Video  filter  numbers  and  bandwidths. 


Video  No. 

Video  Bandwidth 

0 

Off 

1 

1  kHz 

2 

10  kHz 

3 

100  kHz 

4 

1  MHz 

5 

5  MHz 

Table  E-4  -  xp 

I  contents. 

No.  X  j  *  |  Contents 

Usual 

Value’ 

1  “special”  loop  time  (ms) 

36 

2  “stepmod”  loop  time  (ms) 

40 

3  “ownswp”  loop  time  (ms) 

35 

4  "AMown"  loop  time  (ms) 

40 

5  Fraction  of  spot  RI  BW  from  fill  0.2 

6  Max.  output  power,  250-500  MHz  VCOs  (dBm)  16.5 

7  Max.  output  power,  0.500-1  GHz  VCOs  (ddm)  16.5 


8  Max.  output  power,  1-2  GHz  VCOs  (dBm)  17 

9  Max.  output  power,  2-4  GHz  VCOs  (dBm)  17 

10  Max.  volt.,  WI75  into  FM  aux.  (V)  2 

11  dB/V  slope,  W175  into  AM  aux.  5.5 

12  W$  data.  min.  voltage  (V)  0.1 

13  W$  data,  AV  between  entries  (V)  0.2 

14  Max.  volt,  WI75  into  AM  aux.  (V)  5.0 

*  As  of 40  Sep  1981. 


changes  and  the  WI75  is  used  for  FM.  The  user  may 
read  the  contents  of  W$  but  should  never  assign  to 
it. 
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VS  [120 1  is  used  by  the  “loadS”  subrouiine 
blocks  when  transferring  data  from  tape  to  con¬ 
troller.  It  may  be  assigned  by  the  user  if  desired;  how¬ 
ever,  the  user-assigned  contents  would  be  tost  when 
“loadS”  is  called. 

US  1 36  ]  is  used  or  read  by  several  of  the  subroutine 
blocks.  It  is  used  to  pass  data  from  subrouiine  blocks 
to  the  WI75  arbitrary  waveform  generators,  to  hold 
an  operator’s  entry  in  “inRFid,”  and  to  hold  the 
calibration  identification  retrieved  by  “initial.”  US 
must  also  be  used  for  any  operator  inputs  that  are  to 
use  the  “enter”  subroutine  block  (see  Appendix  C). 
The  user  may  make  other  assignments  to  US  as 
desired;  however,  the  user-assigned  contents  would 
be  lost  if  “swpl75,”  “AM175,”  “DC'175,” 

“inRFid,”  or  "initial”  are  called. 

X  [  1 4 1  holds  various  long-term  constants  and  sub¬ 
routine  block  parameters,  such  as  loop  times,  WI75 
voltage  factors,  and  the  fraction  of  a  noise  spot  gen¬ 
erated  from  the  fill  oscillator  (see  Table  E-4).  It  may 
be  dimensioned  larger  than  14  elements,  especially  if 
the  user  wants  to  save  new  long-term  constants,  such 
as  loop  times  for  user-written  run  type  subroutines 
(see  Appendix  D).  The  user  may  change  the  X  ( *  | 
contents  (either  temporarily  during  a  test  or  perman¬ 
ently  by  retaping)  to  match  changed  simulator  condi¬ 
tions,  such  as  a  slower  nextval  subroutine  (see 
Appendix  D). 

Of  special  interest  is  X  [  5  | ,  which  contains  a  frac¬ 
tional  number  (0-1)  indicating  what  proportion  of  a 
noise  spot  should  be  generated  from  the  fill  oscilla¬ 
tor,  with  the  remainder  coming  from  the  noise  gener¬ 
ator.  As  part  of  a  program,  the  user  can  assign  new 
fractions  to  X[5|  and  so  vary  the  results  when 
"fnoise”  is  called  with  otherwise  identical  param¬ 
eters. 

The  simple  variables  U  to  Z  are  used  for  a  number 
of  purposes  by  the  subroutine  blocks.  The  simple 
variables  do  not  need  to  be  dimensioned  unless  the 
user  plans  to  record  the  variables  on  tape.  Simple 
variables  within  subroutine  blocks  are  chiefly  used  as 
for/nexi  loop  indices  and  to  pass  values  from  one 
subroutine  back  to  another,  which  called  the  first 
(e.g.,  from  a  nextval  to  its  calling  subrouiine). 

When  only  one  value  is  returned  by  a  subroutine,  it 
could  be  rewritten  as  a  subroutine  function  and  so 
would  not  need  to  use  a  simple  variable.  The  indirect 
return  through  a  global  variable  from  one  subroutine 
to  the  other  is  more  directly  applicable  when  more 
than  one  value  is  returned,  though  it  would  also  be 
oossible  to  pass  extra  p-numbers  and  have  the  values 
returned  through  those.  The  one  real  advantage  of 


using  simple  variables  to  hold  return  values  comes  in 
checking  software,  particularly  after  a  crash,  since 
simple  variables,  unlike  p-numbers,  are  not  lost  when 
the  controller  is  reset. 

The  simple  variable  Z  is  used  to  set  up  error  codes 
(“err  sip”)  in  a  manner  independent  of  the  p 
numbers;  thus,  assigning  an  error  code  to  Z  will  not 
lead  to  overwriting  some  p-number  whose  value 
would  prove  useful  in  debugging  that  error. 

The  user  may  use  the  simple  variables  U  through  Z 
if  so  desired,  subject  to  the  usual  caution  that  the 
user-assigned  value  will  be  overwritten  and  lost  if  a 
called  subroutine  block  uses  that  variable.  The  user 
must  avoid  stacking  for/ next  loops  in  such  a  way  that 
an  inner  loop  and  an  outer  loop  have  the  same  vari¬ 
able  as  the  index.  This  includes  cases  in  which  the 
inner  loop  is  part  of  a  subroutine  called  by  the  outer 
loop.  For  reference,  the  subroutine  block  uses  of  the 
simple  variables  are  listed: 

U  -  internal  return, 

V  -  for/next  index  (“fval#”),  internal  return, 

W  -  internal  return  (especially  “fval#"), 

X  -  for/next  index, 

Y  -  for/nexi,  internal  return,  and 

Z  -  “err  sip”  eode,  internal  return. 

The  data  values  held  in  Z$,  X$,  YS,  and  W$,  are 
not  constants  but  are  subject  to  change,  due  in  partic¬ 
ular  to  each  VCO’s  voltage-frequency  relation's 
drift  with  time.  The  data  should  be  recalibrated  peri¬ 
odically.  When  to  recalibrate  is  an  empirical 
decision,  with  once  a  week  as  an  estimate.  A  calibra¬ 
tion  program  has  been  written  that  will  set  up  the 
simulator  for  calibration  and  that  will  properly  man¬ 
ipulate  and  store  output  measurements.  An  operator 
may  choose  to  recalibrate  the  entire  simulator  or  just 
part  of  it  (e.g.,  just  recalibrate  the  tune  data  for  one 
VCO). 

Recalibration  introduces  the  need  to  keep  track  of 
the  calibration  data  in  use,  so  that  an  operator  can 
confirm  that  the  data  are  current.  The  calibration 
program  prompts  the  operator  to  provide  a  calibra¬ 
tion  identification  line,  which  would  usually  be  the 
date  of  the  calibration.  This  identifier  is  saved  with 
the  data  and  will  be  printed  on  the  FiP9825's  inter¬ 
nal  printer  whenever  “initial"  is  called. 

A  transfer  program  has  also  been  written  to  have 
the  controller  transfer  the  data  on  one  tape  (e.g.,  the 
calibration  program  tape)  to  other  tapes.  With  a  little 
practice  it  is  possible  to  completely  recalibrate  both 
VCO’s  in  an  rf  channel  in  about  45  min. 
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APPENDIX  F 

ERROR  HANDLING 


This  appendix  summarizes  how  ihe  simulator  sub¬ 
routine  blocks  handle  errors.  The  user’s  program 
may  choose  to  handle  errors  differently,  so  in  addi¬ 
tion  to  summarizing  the  subroutine  block  behavior, 
the  appendix  will  give  a  number  of  suggestions  on 
different  ways  of  handling  errors.  The  reader  should 
also  read  Appendix  C,  which  contains  notes  and 
suggestions  on  subroutine  parameter  checking. 

The  subroutine  blocks  carry  out  a  number  of 
checks  on  the  parameter  values  passed,  chiefly  to 
ensure  that  the  values  are  legal  and  within  range. 
Each  subroutine’s  checks  are  independent,  and  it  is 
up  to  the  user  to  check  combinations  of  subroutine 
blocks.  For  example,  in  setting  a  noise  spot,  the  sub¬ 
routine  block  (“fnoise”)  will  check  that  the  spot 
parameters  are  legal.  It  would  be  the  responsibility  of 
the  user  to  ensure  that  the  spot  remains  legal  if  the 
spot’s  tune  center  is  changed  (e.g.,  a  300  MHz  noise 
spot  could  be  legally  set  at  3.2  GHz  but  would  be 
clipped  and  hence  illegal  if  the  center  were  changed  to 
2  GHz). 

When  an  illegal  value  or  other  error  condition  is 
found  by  a  subroutine  block,  there  is  no  efficient  way 
of  having  the  subroutine  fix  that  value.  The  subrou¬ 
tine  blocks,  being  independent,  cannot  identify  how 
the  user  got  the  value  passed  and  so  cannot  return 
there  to  prompt  the  operator  for  a  new  value.  Default 
values  set  by  the  subroutine  blocks  to  replace  bad 
values  are  unacceptable  because  they  would  give  the 
user  and  operator  a  false  idea  of  what  the  simulator  is 
doing;  even  when  defaults  are  reported,  there 
remains  the  objection  that  the  simulator  would  not 
be  doing  what  the  test  wants  as  indicated  by  the 
passed  values. 

When  a  subroutine  block  detects  an  error,  it  will 
set  a  coded  error  report  number  in  Z  and  then  branch 
to  the  "err  stp”  label.  The  “err  sip,”  properly 
speaking,  is  not  a  true  subroutine  but  becomes  part 
of  whatever  subroutine  entered  it.  When  entered, 
“err  stp”  will  remove  the  simulator’s  outputs  by 
setting  the  RF  channel  function  control  cards  to  the 
same  state  they  are  in  after  “initial;"  carriers,  fill, 
and  noise  are  turned  off.  The  50  ohm  outputs  of  the 
WI75’s  are  also  turned  off.  This  forces  the  operator 
to  correct  the  fault,  preventing  the  fault  from  being 


overlooked  and  the  simulator  from  being  used  in  a 
frozen  slate  (output  fixed  as  it  was  when  the  error 
was  found). 

After  removing  the  simulator’s  output,  "err 
stp"  will  formal  and  print  the  error  code  passed  in 
Z.  This  three-part  code  indicates  the  subroutine  that 
entered  “err  stp"  and  the  reason;  it  may  also  indi¬ 
cate  the  VCO  number  that  was  passed,  as  a  clue  to 
where  in  a  program  the  bad  call  was  made.  (The 
controller  presently  has  no  capability  to  save  the 
current  line  number,  aside  from  deliberately  causing 
a  controller  error  so  as  to  set  the  erl  label.  See  the 
remarks  toward  the  end  of  Appendix  C).  Table  F-l 
lists  the  subroutine  block  error  codes. 

Table  F-1  -  Error  codes. 

1 .  fset 

0  -  illegal  VCO  number 

2.  fval# 

*0  -  frequency  less  than  minimum 
*1  -  frequency  greater  than  maximum 
'2  -  D/A  number  out  of  bounds 

3.  pulse 

0  -  illegal  VCO  number 
*1  -  illegal  source  number 

4.  biph 

0  -  illegal  VCO  number 
*1  -  illegal  VCO  number 

5.  fnoise 

0  -  illegal  VCO  number 
*1  -  spot  BW  about  center  frequency  out  of 
range 

*2  -  illegal  video  number/BW 
*3  -  band  part  frequency  out  of  band 
*4  -  spot  BW  too  large 

6.  auxmod 

0  -  illegal  VCO 

•  I  -  illegal  source  number 

7.  ampsel 

0  -  illegal  VCO  number 

*  I  -  dB  out  of  range 
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8.  AMown 

0  -  illegal  VCO  number 

*  1  -  rate  out  of  range 

*2  -  “AMval”  return  out  of  range 

9.  ownswp 

0  -  illegal  VCO  number 

*  1  -  dwell  per  step  too  high 
*2  -  dwell  per  step  too  low 

10.  setVCO 

0  -  illegal  VCO  number 

1 1 .  stepmod 

0  -  illegal  VCO  number 
*1  -  “stepval”  return  out  of  bounds 
'2  -  “stepwt”  return  out  of  bounds 

12.  special 

0  -  illegal  band  number 
“1  -  illegal  table  length 
2  -  rate  out  of  range 

13.  loadYS,  -  X$,  -  W$ 

0  -  illegal  VCO  number,  -  Y$ 

+  I  2nd  VCO  in  same  RF,  -  Y$ 

2  -  illegal  VCO  number,  -  X$ 

+  3  -  illegal  video  filler  number,  -  X$ 

+  4  -  2nd  VCO  in  same  RF,  -  X$ 

5  -  illegal  VCO  number,  -  W$ 

+  6  -  2nd  VCO  in  same  RF,  -  W$ 

14.  swpl75 

0  -  illegal  VCO  number 

*  I  -  rate  out  of  bounds 

*2  illegal  function  number 

*3  deviation  about  center  frequency  out  of 

range 

*4  -  required  voltage  out  of  range 

15.  DC  1 7 5 

+  0  -  illegal  VCO  number 

1  -  2nd  VCO  in  same 

2  -  illegal  WI75  idem,  number 

3  -  %  duty  cycle  out  of  range 

4  -  period  out  of  bounds 

16.  T/P 

0  -  rate  out  of  bounds 
t  1  -  illegal  VCO  number 
2  -  2nd  VCO  in  same  RF 


17.  AMaux 

0  -  illegal  VCO  number 
*1  -  illegal  source  number 

18.  AM  175 

0  -  illegal  VCO  number 
*1  -  rate  out  of  bounds 
*2  -  illegal  function  number 
*3  -  max.  dB  out  of  bounds 

Notes:  *  Third  part  of  code  will  be  VCO  number. 

+  Third  pan  of  code  will  be  parameter  list 
position  number. 

■•Third  part  of  code  will  be  band  number. 

After  printing  the  error  code,  “err  sip”  goes  into 
an  endless  message  loop,  flashing  an  operator  notice 
and  beeping.  There  is  no  explicit  exit  from  this  loop. 
The  operator  must  stop  the  controller  to  get  out  of 
the  message  loop.  This  forces  the  operator  to  take  an 
active  step  to  recover  from  such  a  crash. 

Once  the  message  loop  has  been  stopped,  further 
actions  for  recovery  are  up  to  the  operator.  The  local 
p-numbers  can  be  read  by  the  operator  as  an  aide  in 
debugging,  if  the  controller  has  not  yet  been  reset. 
The  controller  should  be  reset  before  continuing  on 
to  fix  the  test  in  order  to  clear  the  subroutine  address 
return  pointers. 

Similar  to  “err  sip”  is  “shutoff,"  which  will 
perform  similar  simulator  shutoff,  fault  reporting, 
and  message  loop  functions  when  the  controller  de¬ 
tects  an  error.  The  user  must  enable  “shutoff”  as 
an  error  recovery  routine  if  it  is  to  be  used;  otherwise, 
controller  errors  will  result  in  the  controller  stopping 
with  the  simulator  output  frozen  at  its  state  when  the 
controller  fault  was  detected.  To  enable  “shutoff," 
the  user  should  include  this  line  in  the  program’s 
initialization: 

on  err  “shutoff" 

Recovery  from  “err  stp"  or  “shutoff"  depends 
on  the  details  of  the  user’s  program.  The  operator 
can  always  rerun  the  test  from  the  beginning,  making 
the  necessary  corrections  in  the  rerun  (if  there  are 
corrections  to  make;  recovery  from  a  controller  fault 
due  to  tape  read  errors  is  usually  a  matter  of  trying 
again).  If  the  operator  knows  of  a  program  location 
from  which  corrections  can  be  made  and  the  test  con¬ 
tinued  rather  than  rerun,  this  would  save  time  and 
tape  wear.  The  user  may  provide  a  convenient  mne¬ 
monic  label  (i.e. ,  "start"  or  “recovery")  that  the 
operator  can  use. 
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It  should  be  noted  that  neither  “err  stp”  nor 
“shutoff”  affects  the  Z[*  J  contents,  so  the  simula¬ 
tor  could  be  restored  to  its  precrash  state  by  sending 
the  Z  [  *  ]  contents  out  to  the  channel  function  control 
cards  and  (if  needed)  tuning  on  the  W175  50  ohm 
outputs.  The  Z  [  *  1  contents  can  be  sent  to  the  func¬ 
tion  control  cards  by  using  any  subroutine  that 
affects  those  cards,  or  the  Z  [2]  through  Z[  12]  con¬ 
tents  could  be  sent  directly  to  the  multipro¬ 
grammer. 

Error  handling  by  the  user's  program  can  be  far 
more  extensive  than  simply  providing  a  label  for  an 
operator  to  use.  It  is,  of  course,  easier  to  catch  errors 
before  they  result  in  a  crash.  The  user  can  provide  ex¬ 
tensive  checking  of  operator  inputs  to  catch  bad 
values  before  they  are  passed  to  the  subroutine 
blocks  (see  Appendix  C). 

The  user  can  also  check  combinations  of  parame¬ 
ters  and  prompt  the  operator  to  correct  any  faults  or 
conflicts.  Of  particular  interest  is  the  allocation  of 
the  two  W175's  among  the  three  uses  of  fm,  am,  and 
pulse.  The  user  should  track  such  WI75  use  to  make 


sure  that  no  conflicts  arise  (e  g.,  if  the  AM  W|75  iv 
used  for  AM,  the  user  should  make  sure  that  an  ki 
channel’s  pulse  circuit  is  not  actively  connected  to 
that  W]75  because  the  waveforms  and  voltages  may 
not  be  compatible).  Usually  such  device  tracking  is 
implicit  in  a  program. 

The  user  can  also  provide  more  extensive  error 
recovery  routines  to  replace  "shutoff”.  The  user 
might  allow  recovery  from  certain  errors  (e.g.,  can 
repeat  a  tape  load  a  fixed  number  of  tries  if  a  tape 
read  error  is  found),  with  unrecoverable  errors 
handled  by  branching  to  “shutoff”  much  as  the 
subroutine  blocks  branch  to  “err  stp.” 

The  amount  of  error  checking  provided  by  the  user 
may  range  from  none  to  very  extensive.  Users  will 
probably  provide  checks  and  recoveries  for  any  faults 
or  errors  considered  likely  and  leave  the  rest  to  the 
subroutine  blocks  and  the  controller.  There  is  a 
trade-off  effort  between  recovering  from  an  error 
without  user-provided  help  and  in  the  user’s  efforts 
and  time  in  providing  that  help.  Trade-off  choices 
are  up  to  each  user  in  each  test  program. 
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APPENDIX  G 


TAPE  USE 


Programs  and  data  for  the  HP9825  controller  are 
saved  on  a  magnetic  tape  cartridge.  This  appendix 
describes  several  restrictions  on  and  suggestions  for 
tape  use.  The  user  is  assumed  to  be  familiar  with  the 
basic  tape  use  instructions  as  given  in  the  HP9825 
reference  manual. 

Tape  use  is  restricted  in  that  files  1  through  91  on 
track  I  are  reserved  to  hold  the  subroutine  block  data 
(see  Table  6).  The  reservations  require  about  20%  of 
the  available  tape  on  track  1.  When  a  new  tape 
cartridge  is  prepared  for  use,  the  data  files  must  first 
be  marked.  A  convenient,  easy-to-type  instruction 
that  will  mark  each  file  is: 

trk  1;  rew;  mrk  1,  XXXX; 
mrk  6,  800;  mrk  84,  150; 
mrk  1 , 60. 

This  instruction  can  be  typed  and  executed  as  one 
line  from  the  keyboard.  The  string  files  will  be  a  few 
bytes  larger  than  is  actually  necessary;  this  is  not  sig¬ 
nificant.  The  file  that  holds  X  [  *  ]  should  be  marked 
somewhat  larger  than  needed  to  allow  for  future 
growth  such  as  the  addition  of  user-written  loop 
times  (see  Appendix  D).  File  0  of  track  1  is  available 
to  the  user;  in  the  marking  line  above,  XXXX  stands 
for  the  user-selected  size  of  this  file. 

When  the  subroutine  block  data  files  have  been 
marked,  the  contents  can  be  loaded  using  the  transfer 
program  and  any  older  tape  (calibration  or  test  pro¬ 
gram)  that  has  the  data  to  be  loaded.  When  the  trans¬ 
fer  is  complete,  the  user  may  record  the  transfer  pro¬ 
gram  itself  on  the  new  tape  for  possible  future  use. 

In  addition  to  the  data  files  on  track  1,  the  user 
must  mark  a  file  somewhere  to  hold  the  subroutine 
blocks.  The  actual  file  locations  and  track  are  up  to 
the  user.  Typically  a  new  tape  will  include  one  master 
file  containing  all  of  the  subroutine  blocks,  and  it 
may  contain  other  files  holding  smaller  subsets  of  the 
subroutine  blocks  for  use  in  programs  where  memory 
efficiency  is  important.  File  0  of  track  1  would  be  a 
logical  place  to  put  the  master  subroutine  block  file, 
if  the  file  is  marked  large  enough. 

There  is  a  use  for  file  0  of  track  0  that,  while  not 
required,  is  suggested  as  a  good  way  of  identifying 
'apes  and  providing  at  the  same  time  against  a  power 


on/off  cycle  leading  to  an  undesired  test.  If  a  tape 
cartridge  is  in  the  controller  when  the  power  goes 
from  down  to  up,  the  controller  will  automatically 
attempt  to  load  and  run  the  program  contents  of  file 
0  of  track  0.  A  tape  (especially  one  containing  several 
tests)  should  generally  avoid  putting  a  test  program 
in  that  file  in  order  to  avoid  unintentionally  running 
that  program  if  the  controller’s  power  is  cycled 
on/off/on  with  the  operator  busy  elsewhere. 

The  autoload  and  run  are  useful,  however,  in  cases 
where  the  user  wants  a  certain  program  to  run  with¬ 
out  that  program  having  to  be  separately  loaded. 
Demonstration  tapes  might  use  this  feature  to  start 
their  demonstration  as  soon  as  power  is  turned  on. 
More  generally,  file  0  of  track  0  can  be  used  as  an 
index  to  the  rest  of  the  tape.  Such  an  index  could 
identify  the  test  programs  available  on  that  tape  and 
could  include  some  general  information  on  their  use 
The  index  can  be  written  to  allow  the  operator  to 
select  which  test  to  run  by  naming  a  menu  selection, 
with  the  necessary  load  program  (Idp)  being  carried 
out  by  the  index  program. 

An  index  program  can  mix  use  of  the  controller's 
display  and  printer.  A  typical  arrangement  would  use 
the  printer  to  list  the  available  test  programs  and 
their  file  numbers,  and  the  display  to  give  informa¬ 
tion  about  those  tests.  When  using  the  display  in  an 
index  program,  the  user  can  allow  the  operator  to 
self-lime  the  display  by  using  the  stop  instruction 
rather  than  wait  after  each  display  instruction.  The 
pointer  or  first  display  can  prompt  the  operator  to 
press  CONTINUE  to  self-time  the  following 
messages.  This  is  similar  to  what  the  user  can  do  in  a 
dedicated  help  type  information  program  (see  Ap¬ 
pendix  C). 

If  stop  is  used,  two  points  should  be  kept  in  mind. 
First,  the  operator  should  be  given  a  definite  indica¬ 
tion  when  the  end  of  the  file  0  contents  has  been 
reached  and  should  be  told  to  keep  pressing 
CONTINUE  until  done  (so  the  operator  does  not 
assume  the  index  is  done  before  it  actually  is  and  so 
lose  some  information).  Second,  when  mixing  print 
and  display  statements,  the  user  should  arrange  them 
so  that  the  display  is  not  wiped  out  when  the  printer 
is  used.  This  can  be  done  by  simply  not  using  stop 
after  a  print. 
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The  user  can  also  indicate  the  contents  of  a  tape  by 
using  the  HP9825’s  (list  instruction.  The  paper  tape 
list  of  the  magnetic  tape  files  can  then  be  marked  by 
writing  each  file’s  name  or  purpose  next  to  the  file 
number.  This  paper  would  be  kept  with  the  magnetic 
tape  and  could  be  used  by  an  operator  as  a  quick 
guide  to  what  file  to  load  to  get  a  desired  test. 

The  basic  idea  behind  using  the  tlist  paper  or  file  0 
of  track  0  or  both  is  to  give  the  operator  a  ready  indi¬ 
cation  as  to  the  tape  contents.  The  operator  should 
not  have  to  load  a  file  in  order  to  find  out  what  it 
contains. 

When  the  user  marks  a  new  file  in  order  to  record  a 
test  program,  data  file,  subroutine  block  subset,  or 
other  program  element,  it  is  recommended  that  the 
file  be  marked  larger  than  is  actually  necessary.  This 
would  allow  for  easy  expansion  if  the  program  ele¬ 
ment  to  be  taped  is  later  modified.  The  amount  of  ex¬ 
cess  marked  space  should  increase  as  the  required  size 
increases  (e.g.,  a  file  for  a  700  byte  element  might  be 
marked  as  1000  bytes,  while  a  9800  byte  element 
could  be  marked  for  12,500  bytes).  The  user  should 
avoid  having  to  mark  a  new  file  (or  remark  an  entire 
tape)  if  the  contents  of  a  file  are  later  modified  to  be 
larger  than  the  marked  size.  It  is  quite  easy  to  have  a 
9K  byte  program  grow  to  10. 5K  bytes,  which  would 
be  a  problem  if  the  file  for  that  program  had  been 
marked  for  10K  bytes.  However,  no  file  need  be 
marked  larger  than  the  total  available  memory  size  of 
the  controller  (currently  22,910  bytes). 

If  the  user  writes  a  long  program  or  needs  a  large 
data  table  for  a  run  type  subroutine  (e.g.,  "spe¬ 
cial”),  the  program  can  be  written  as  a  number  of 
separately  taped  segments,  so  that  at  any  given  time 
only  the  needed  segment  would  be  in  controller 
memory.  This  differs  from  a  program  that  may  be 
taped  in  several  segments  but  runs  as  one  (e.g.,  separ¬ 
ately  taped  program  and  subroutine  blocks).  A  pro¬ 
gram  written  and  taped  so  that  only  part  of  it  is  in 
memory  at  any  time  can  be  termed  a  multisegment 
program. 

Multisegment  programs  would  be  ordered  so  that 
each  segment  contains  a  complete  interval  or  several 
intervals.  The  user  should  be  aware  that  loading  a  file 
can  take  some  time,  the  actual  time  depending  on  the 
length  of  the  file  to  be  loaded  and  the  time  needed  to 
find  that  file,  which  depends  on  where  the  track  head 
happens  to  be  when  the  load  is  called.  Timing  consid¬ 
erations  may  be  used  in  deciding  the  intervals  in  a 
segment. 

In  using  a  multisegment  program,  the  user  would 
link  the  segments  with  the  load  file  (ldf)  instruction. 


which  keeps  data  values  intact  by  continuing  after  the 
load.  The  load  program  (ldp)  instruction  runs  after 
the  load  and  so  would  wipe  out  all  data  values  and 
dimensions.  This  effeci  of  ldp  may  be  useful  in 
passing  from  one  independent  program  to  another 
since  it  lets  each  program  use  whatever  variables  it 
needs,  independent  of  the  other  program.  An  index 
program  as  mentioned  above  would  be  a  good  place 
to  use  ldp  rather  than  ldf. 

When  using  multisegment  programs,  the  user  must 
avoid  overwriting  any  instructions  that  should  be  left 
in  the  controller.  This  can  be  done  by  using  explicit 
line  numbers  in  ldf  for  the  load  line  and  the  continue 
line.  This  does  require  the  user  to  keep  explicit  track 
of  the  right  line  numbers  since  the  HP9825  controller 
presently  has  no  readily  accessible  capability  of 
tracking  line  numbers. 

The  explicit  line  numbers  can  complicate  program 
modifications  that  add  or  delete  (or  otherwise 
change)  line  numbers.  The  user  in  such  cases  mvst 
avoid  unintentional  returns  after  a  modification.  One 
way  would  be  to  use  a  number  of  null  lines.  The  load 
and  continue  line  numbers  could  be  located  in  the 
middle  of  eight  or  ten  null  lines,  so  that  addition  or 
deletion  of  a  few  lines  will  not  hurt  if  the  user  forgets 
to  change  the  line  numbers. 

Whenever  the  user  has  tape  operations  inside  a 
program  (data  loads,  program  files,  or  multisegment 
changes),  it  would  be  a  good  idea  u)  specify  explicitly 
the  track  number  rather  than  specifying  it  implicitly. 
This  amounts  to  including  the  track  statement  with 
every  tape  operation,  rather  than  only  when  it 
changes  from  its  previous  value.  This  is  especially 
desirable  whenever  the  operator  can  affect  the  tape 
track  (which  can  be  done  from  the  live  keyboard). 
Much  of  the  time  this  would  be  an  extraneous  step, 
but  it  can  avoid  ambiguity  and  incorrect  track  use. 

The  user  may  also  include  steps  to  ensure  that  the 
tape  track  is  known  when  the  tape  is  removed  from 
the  controller  by  putting  the  tape  to  track  0  after  the 
last  tape  use.  Determining  when  and  where  the  last 
tape  use  occurs  will,  of  course,  depend  on  the  details 
of  the  user’s  program. 

There  are  also  a  few  suggestions  the  user  can 
follow  to  increase  tape  life  and  reduce  read  and 
record  errors.  After  the  last  tape  use,  the  program 
could  execute  the  rewind  instruction.  There  should  be 
no  noticable  time  penalty  to  this,  and  it  will  cover 
against  the  operator  failing  to  press  the  rewind  key- 
before  removing  a  tape.  Tapes  should  be  rewound 
when  removed  from  the  controller  for  any  length  of 
time  in  order  to  protect  the  tape  and  its  contents. 


45 


TH€  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

LAURt  Maryland 


The  user  should  avoid  putting  all  files  on  the  first 
few  inches  of  tape  or  putting  a  heavily  used  file  there 
because  doing  so  would  lead  to  increased  tape  slack 
and  decreased  life.  The  user  may  simply  dimension 
file  0  on  track  0  very  large  (say,  I0K  bytes),  with  the 
program  files  following  on  the  same  track. 

Tapes  should  be  completely  rewound  occasionally 
or  whenever  visual  inspection  of  the  tape  cartridge 
shows  the  tape  is  wound  unevenly.  The  HP9825  users 
guide  has  suggestions  on  how  to  do  this.  The  user  can 
also  erase  the  tape  from  the  last  numbered  file  on 
either  track  and  then  rewind  the  tape.  If  this  is  done, 
the  user  (or  operator  reminded  by  the  user)  should  be 
sure  to  specify  the  track  number  and  null  file 
number,  or,  obviously,  unpleasant  results  could 
follow. 


The  user  is  urged  to  prepare  backup  copies  of  every 
program  tape  and  to  keep  those  copies  separate.  This 
provides  protection  against  tape  loss  or  destruction. 
It  also  allows  the  user  to  modify  a  file  and  try  ii  out 
on  a  test  run  before  copying  it  to  the  backup  tapes,  so 
that  if  the  modification  does  not  work  or  is  undesir¬ 
able.  a  copy  of  the  unmodified  program  will  be 
available. 

If  a  tape  does  not  have  any  files  recorded  by  a  pro¬ 
gram  during  a  test  (i.e.,  if  nothing  is  written  to  the 
tape  after  the  user  prepared  it),  the  tape  can  be  pro¬ 
tected  from  accidential  use  of  record  file  (ref)  for 
load  file  (Idf)  by  using  the  slide  tab  on  the  tape  cart¬ 
ridge.  Using  the  tab  means  that  the  tape  cartridge 
must  be  consciously  prepared  in  order  to  write  new 
file  contents  onto  it. 
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APPENDIX  H 


W175  ARBITRARY  WAVEFORM  GENERATOR  USE 


This  appendix  describes  some  details  on  the  use  of 
the  W175  arbitrary  waveform  generator  as  part  of 
the  simulator.  It  does  not  serve  as  a  general  guide  to 
the  W175;  for  that,  the  user  is  referred  to  the  W175 
instruction  manual  (especially  Sections  1  and  3).  it 
will  be  assumed  in  this  appendix  that  the  user  is  fam¬ 
iliar  with  the  W175  and  knows  how  to  set  it  up.  The 
user  may  be  reminded  that  the  letter  character  codes 
for  the  various  W175  data  are  printed  in  the  lower 
left  corner  of  the  corresponding  key,  which  provides 
a  convenient  reference  for  those  codes  with  typing  in¬ 
structions  to  the  simulator  controller. 

W175  users  may  specify  the  state  of  the  arbitrary 
generator  either  by  means  of  a  coded  string  sent  over 
the  bus  or  from  the  W175’s  front  panel.  The  front 
panel  is  easy  to  use  and  lets  an  operator  rapidly  and 
randomly  change  the  W175  settings.  This  is  useful 
when  the  operator  wants  to  observe  the  effects  of  dif¬ 
ferent  settings  without  having  to  go  through  the  con¬ 
troller  and  is  appropriate  when  the  user  is  mainly 
concerned  with  checking  the  resulting  waveform  in 
order  to  observe  its  characteristics. 

However,  the  controller  cannot  check  any  W175 
settings  made  through  the  front  panel.  Some  W175 
settings  that  are  legal  as  far  as  the  arbitrary  generator 
is  concerned  are  illegal  in  certain  simulator  states. 
Examples  of  this  include  feeding  a  bi-sign  (  +  /-) 
voltage  waveform  to  a  pulse  circuit  and  setting  too 
high  a  voltage  for  an  auxiliary  FM  input. 

Whenever  possible,  all  W175  parameters  should  be 
checked  and  set  through  the  controller.  The  addi¬ 
tional  programming  workload  that  results  will  be 
offset  by  increased  confidence  that  the  WI75  setting 
is  legal  and  meaningful.  Using  the  controller  to  set  all 
W175  parameters  also  ensures  repeatability  and  lets 
the  controller  track  and  document  the  settings. 

On  paper,  the  controller  can  prevent  a  bus  device 
(the  WI75  front  panel)  from  being  changed  by  an  op¬ 
erator  by  sending  the  local  lockout  statement  (e.g., 
llo7)  to  any  device  that  will  respond  to  that  bus  line. 
It  could  later  re-enable  the  device  (front  panel)  by 
sending  the  clear  lock/out  local  statement  (e.g.,  lcl 
701),  Peculiarities  have  been  noticed  in  practice  with 
the  W175  front  panel.  When  a  program  is  running, 
the  W175  front  panel  can  be  freely  used  up  to  the 
time  that  some  message  (other  than  bus  clear)  is  sent 


to  it.  After  that,  the  addressed  W175  is  in  a  remote 
mode  and  the  front  panel  keys  cannot  be  used  to 
change  any  settings.  Lockout  need  not  be  sent.  The 
front  panel  can  be  re-enabled  by  the  lcl  statement. 
This  much  is  expected  and  follows  the  bus  response 
description  in  the  W175  instruction  manual.  A  pecu¬ 
liarity  is  that,  when  lcl  is  used,  it  has  been  found  that 
the  W175  will  not  respond  to  any  following  bus 
messages,  unless  the  controller  is  reset.  This  holds  re¬ 
gardless  of  whether  or  not  llo  is  sent  after  lcl. 

To  restate  this,  the  controller  will  lock  out  the 
WI75  front  panel  as  soon  as  it  sends  any  message 
specific  to  that  W175  (clr  701  will  not  cause  a  lock¬ 
out,  but  sending  “ZI”  will).  If  the  lockout  is  ended 
by  the  device  clear  statement  lcl  (which  the  operator 
may  send  independently  of  a  program  by  using  the 
live  keyboard),  the  W 175  will  then  ignore  any  further 
bus  messages. 

In  order  to  avoid  lost  W175  bus  messages,  the 
user’s  program  should  not  send  the  clear  lockout/ 
local  (lcl)  statement,  at  least  not  if  there  are  or  could 
be  later  bus  messages.  If  lcl  is  ever  sent,  then  all 
further  changes  of  that  W'175  must  be  made  by  the 
operator,  until  the  controller  is  reset  (which  must 
reset  the  test  program  as  well).  Nor  should  the  opera¬ 
tor  send  lcl  through  the  live  keyboard,  unless  the  op¬ 
erator  is  aware  of  the  result.  The  user  could  disable 
the  live  keyboard  to  prevent  the  operator  from 
sending  lcl,  but  doing  so  would  keep  the  operator 
from  using  the  live  keyboard  for  anything  else  (in¬ 
cluding  test  control,  especially  if  the  program  uses 
the  controller’s  function  keys  for  anything),  so  dis¬ 
abling  the  keyboard  is  a  discouraged  option. 

Any  trouble  with  the  lockout  and  local  characteris¬ 
tics  of  the  W175  can  be  avoided  by  having  all  W175 
parameters  sent  through  the  controller;  however, 
there  may  be  cases  in  which  the  user  wishes  to  let  an 
operator  vary  some  settings.  The  program  could  give 
the  operator  time  to  use  the  front  panel  by  stopping 
between  initialization  and  the  first  W175  bus 
messages,  with  the  operator  pressing  CONTINUE 
when  done.  This  approach  does  have  the  advantage 
of  being  easy  to  program  and  is  quite  short.  It  is  basi¬ 
cally  a  one-time  item  for  each  test  run. 

A  better  way  of  having  an  operator  set  up  the 
WI75  would  be  for  the  operator  to  specify  the  con- 
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letits  of  the  message  string  sent  over  the  bus.  This  can 
be  done  with  the  live  keyboard  and  a  quoted  char¬ 
acter  string  if  the  operator  knows  the  right  bus 
address  (see  Table  H-l).  It  can  also  be  done  by 
having  the  controller  prompt  the  operator.  If  the  op¬ 
erator  is  knowledgeable  and  the  user  wants  or  needs  a 
short,  easy-to-program  input,  the  operator  could 
enter  the  message  string  directly,  with  addressing  and 
perhaps  some  simple  checking  and  manipulation 
done  by  the  user’s  program.  If  U$  or  V$  are  used  to 
pass  the  message  (which  would  save  the  user  from 
having  to  dimension  a  new  string),  they  should  first 
be  cleared  with  null  assignments  (e.g.,  —  VS).  The 

user  could  make  sure  the  string  contains  upper-case 
characters  by  using  the  cap  function  and  could  check 
that  the  last  character  is  the  W175  execute  symbol 
("I”),  adding  it  if  it  were  missing.  The  user’s  pro¬ 
gram  might  also  prompt  the  operator  through  all  the 
W175  options  but  this  would  require  far  too  much 
programming  effort  and  space  to  be  practicable. 

There  are  three  uses  for  the  arbitrary  waveform 
generators  (FM,  AM,  pulse)  but  only  two  WI75’s,  so 
the  user’s  program  must  allocate  each  W175  be¬ 
tween  FM  and  pulse  or  am  and  pulse.  If  a  test  would 
require  all  three  uses,  the  program  must  find  a  differ¬ 
ent  source  for  one  of  the  three.  If  an  external  source 
is  not  available,  the  simulator’s  multiprogrammer 
cards  can  be  used.  For  example,  FM  and  pulse  signals 
could  be  taken  from  the  W175’s,  with  AM  being  run 
through  the  controller  (“AMown”)  using  the  D/A 
cards  in  the  HP6943  extender.  If  a  pulse  signal  is  a 
50%  duty  cycle  square  wave,  it  can  be  generated 
through  the  timer/pacer  card,  and,  if  it  is  at  a  10  or 
100  Hz  rate,  it  could  be  taken  from  the  Rt  channel 
pulse  sources,  leaving  the  W!75’s  free  for  I'M  and 
AM. 

What  the  user  wants  to  avoid  is  having  a  WI75  set 
up  for  one  use  with  the  resulting  signal  being  fed  to 
the  wrong  circuit  on  some  rf  channel.  This  would 


Table  H-1  -  Bus  addresses 

Address 

Device 

723 

HP6942/3  multiprogrammer  and  extender 

701 

FM  WI75  (B) 

702 

AM  WI75  (A) 

703 

492P  spectrum  analyzer  (optional) 

Vue:  HP6943  extender  is  at  frame  number  100. 


give  a  confusing  and  incorrect  simulator  setup.  The 
waveforms,  rates,  voltages,  and  offsets  suitable  for 
one  modulation  type  use  are  unlikely  to  be  suitable 
for  the  other  type  use. 

If  a  W1 75  is  set  as  a  pulse  source,  its  50  ohm  out¬ 
put  would  be  turned  off.  If  the  pulse  source  W  175 
were  used  as  an  FM  or  am  source  in  connecting  an  Kl 
channel  through  the  auxiliary  switch  matrix 
(“auxmod”  or  “AMaux”  with  a  source  number 
of  3),  there  would  be  no  actual  fm  or  am  (aside  from 
any  leakage).  If  a  W175  is  set  up  for  fm  or  am,  the  50 
ohm  output  will  be  on,  but  there  is  no  way  of  turning 
off  the  0  ohm  output.  Thus,  if  the  FM  or  am  source 
W175  were  used  as  a  pulse  source  in  setting  an  ri 
channel’s  pulse  circuit  (“pulse”  with  a  source 
number  of  3  or  4),  the  FM  or  AM  signal  would  be  fed 
to  the  pulse  circuit.  This  would  not  damage  the  hard¬ 
ware,  but  it  would  give  an  incorrect  idea  of  the  simu¬ 
lator  status,  especially  to  anyone  monitoring  the  sim¬ 
ulator  status  LED’s  but  not  the  RF  output. 

It  is  important  that  the  user  keep  track  of  the  use 
of  each  W175  in  order  to  avoid  conflicts,  especially 
when  a  W175’s  use  may  be  changed  during  a  test. 
Tracking  is  usually  implicit  in  what  the  program  does 
but  may  need  to  be  done  explicitly,  especially  when 
an  operator  controls  the  sequence  of  test  intervals. 
Tracking  can  be  done  by  setting  or  clearing  the  con¬ 
troller’s  flags  (or  any  other  user-assigned  variables) 
to  indicate  the  use. 

When  setting  a  WI75’s  function  block  frequency 
or  rate,  the  user  should  keep  two  things  in  mind. 
First,  what  is  actually  being  set  is  the  sample  lime  per 
block  point.  If  the  block  size  were  changed  after 
setting  a  block  rate,  then  the  block  rate  would 
change,  since  the  output  would  involve  the  same 
sample  time  per  point  over  a  different  number  of 
points.  If  the  block  rate  and  block  size  are  changed  in 
the  same  message  string,  the  order  is  important.  That 
the  block  rate  will  change  when  the  block  size  does 
can  be  exploited  as  a  quick  way  of  changing  the  rate, 
since  it  takes  about  25  ms  to  change  block  size  as 
opposed  to  50  ms  to  change  block  rate  (see  Section  1 
of  the  W 1 75  instruction  manual). 

Second,  the  user  should  keep  in  mind  that  the 
block  rate  or  block  frequency  is  not  the  same  as  the 
modulation  frequency.  The  block  rate  actually 
describes  the  rate  at  which  the  W175  function  block 
contents  are  sent  out.  A  modulation  frequency  de¬ 
scribes  the  rate  at  which  the  output  modulation  is 
changing. 

The  modulation  rate  of  a  W175  output  is  a  func¬ 
tion  of  the  block  rate,  the  output  amplitude,  and  the 
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function  block  contents  (the  output  waveform).  This 
last  dependence  makes  it  difficult  to  specify  modula¬ 
tion  rates  directly.  The  function  block  contents  are 
not  generally  known  if  a  RAM  block  is  used.  The 
RAM  contents  may  not  be  continuous  or  substan¬ 
tially  monotonic,  may  not  be  full  valued  (may  not 
cover  the  full  amplitude  range  set  on  the  W175,  with 
maximum  Y  value  under  +127  or  minimum  over 
-  127),  and  could  result  in  a  nonuniform  output 
modulation  rate. 

In  some  cases  the  modulation  rate  can  be  easily 
related  to  the  block  rate.  Pulse  rates  (inverse  periods) 
can  be  directly  set,  as  can  rates  given  in  hertz.  Modu¬ 
lation  rates  given  in  units  per  second  (e.g.,  MHz/s, 
dB/s)  can  be  readily  handled  if  the  function  block 
contents  are  well  behaved  (would  give  a  uniform  out¬ 
put  rate)  and  are  full  valued,  and  if  the  modulation 
deviation  is  known.  The  user  would  then  find  the 
block  rate  necessary  for  a  desired  modulation  rate  as 
a  relation  of  the  number  of  times  the  output  covers 
the  modulation  deviation  range  when  the  function 
block  is  sampled  and  of  the  amplitude  of  the  devia¬ 
tion  range.  The  relation  is 


block  rate  (Hz) 


modulation  rate  (unit/s) _ 

f  A' J  [modulation  deviation  (unit)j 


where  k  represents  the  number  of  deviation  swings  in 
one  block  sample  (this  can  be  determined  by  noting 
the  number  of  times  the  Y  value  of  the  block  contents 
changes  by  an  absolute  value  of  255  points).  This 
factor  will  change  if  a  partial  block  is  used. 

The  user  may  find  other  relations  to  use  if  the 
block  contents  are  not  full  valued  (e.g.,  the  user  can 
scale  the  deviation  range  in  the  relation  expression 
above).  If  the  block  contents  are  such  that  the  re¬ 
sulting  modulation  rate  would  be  nonuniform,  it  be¬ 
comes  more  difficult  to  define  and  find  a  relation  be¬ 
tween  block  rate  and  modulation  rate.  It  may  be 
worth  repeating  that,  if  a  modulation  rate  can  be  ex¬ 
pressed  in  hertz,  that  rate  can  be  used  in  setting  the 
block  rate  (with  perhaps  a  k  number  factor  included, 
especially  if  a  RAM  block  with  several  cycles  of  a 
waveform  is  used). 

The  minimum  and  maximum  block  rates  will 
depend  on  the  block  size,  since  the  real  minimum  and 
maximum  of  interest  are  those  of  the  sample  time  per 
point.  These  limits  are  200  ns  (500  ns  for  RAM)  and 
999.9  s  per  point.  Minimum  block  rates  are  unlikely 
to  be  any  problem  because  it  is  difficult  to  think  of 
any  ECM  simulator  modulation  requiring  more  than 
71  hours  for  one  cycle.  Maximum  block  rate  for  a 
full  block  is  19.5  kHz  (7.8  kHz  for  RAM).  If  a  higher 


block  rate  is  needed,  a  partial  block  can  be  used.  The 
user  should  remember,  however,  that  a  partial  block 
has  less  resolution  than  a  full  one.  Also,  maximum 
block  rates  should  be  considered  in  terms  of  the 
response  of  the  modulated  device  (such  as  the  500 
kHz  pulse  circuit  maximum). 

The  subroutine  blocks  that  directly  or  indirectly 
pass  block  rate  to  a  W175  check  the  maximum  rate 
under  the  assumption  that  a  full  non-RAM  block  is 
used,  so  that  the  maximum  accepted  rate  is  19.5  kHz. 
If  the  user  wants  to  pass  a  higher  rate  for  use  with  a 
partial  block,  the  subroutine  blocks  must  be  either 
modified  or  not  used,  or  the  user  may  use  the  subrou¬ 
tine  blocks  to  pass  a  scaled  rate,  up  to  the  maximum 
19.5  kHz  rate,  as  if  for  a  full  block,  then  change  to  a 
partial  block  when  the  subroutine  returns.  The  scaled 
rate  would  reflect  the  size  of  the  partial  block. 

At  present,  the  subroutine  blocks  will  accept  a 
RAM  block  rate  between  7.8  and  19.5  kHz  even 
though  such  rates  are  actually  illegal  and  would  cause 
a  W175  error  (such  an  error  would  give  an  error  dis¬ 
play  on  the  W175  but  would  not  crash  the  simulator). 
It  is  up  to  the  user  to  ensure  that  RAM  block  rates  are 
below  7.8  kHz.  Such  RAM  checking  can  easily  be 
added  to  the  subroutine  block  software  at  a  slight 
increase  in  memory  size  (see  Appendix  K). 

The  subroutine  blocks  will  accept  any  legal  func¬ 
tion  number  to  designate  the  waveform  function 
block  (see  Table  H-2).  It  is  up  to  the  user  to  ensure 
that  RAM  blocks  are  programmed  and  up  to  the  op¬ 
erator  to  ensure  that  PROM  blocks  actually  have 
PROMs.  If  a  RAM  waveform  is  used  very  often  or 
must  be  used  at  a  rate  greater  than  7.8  kHz,  the  RAM 
contents  could  be  programmed  into  a  PROM 
(assuming  the  user  has  a  PROM  programmer  avail¬ 
able)  and  the  PROM  then  used  in  place  of  the 
RAM. 

The  user  will  find  the  RAM  blocks  very  useful 
whenever  a  nonstandard  waveform  is  needed.  When 
high  time  resolution  is  needed,  the  user  can  stack  the 
RAM’s  to  get  up  to  1024  time  points  for  use  in  de¬ 
scribing  the  waveform.  The  RAM’s  must  be  pro¬ 
grammed  separately  and  the  same  block  rate  (sample 
time  per  point)  used  throughout. 

Two  examples  can  help  illustrate  the  usefulness  of 
the  W175  RAM  blocks.  First,  suppose  a  test  design 
called  for  a  signal  to  blink  with  some  particular  pulse 
pattern,  in  which  the  pulse  duration  may  vary  from 
pulse  to  pulse,  to  be  followed  by  a  look-through  or 
off  period,  the  pattern  then  continuing  with  some 
overall  period.  A  W175  can  be  used  as  pulse  source 
with  a  single  RAM  waveform  to  handle  the  complete 
pulse  behavior.  The  RAM  Y  values  would  be  0  or 
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Table  H  2  -  Wl  75  functions. 
f  unction  So.  Function 


0 

Sine 

1 

Triangle 

2 

Square 

3 

Ramp 

4 

-  7 

Single  PROMs 

8 

11 

Single  RAMs 

14 

-  17 

Slacked  PROMs 

(1 , 2,  3,  or  4  stacked) 

18 

-  21 

Stacked  RAMs 

(1, 2,  3,  or  4  stacked) 

Note:  Stacked  RAMs  must  be  individually  programmed. 

+  127  and  the  X  positions  would  specify  the  actual 
overall  pulse  form;  the  block  rate  would  be  the  in¬ 
verse  of  the  overall  period.  Amplitude  and  offset 
would  be  2  and  1  volts,  respectively,  and  the  50  ohm 
output  would  be  off.  The  setup  would  be  somewhat 
similar  to  getting  a  stable  pulse  waveform  using 
‘‘DC175”  but  more  flexible.  The  user  could  thereby 
get  the  complete  blinking  and  look-through/off  be¬ 
havior  without  involving  the  controller  other  than  to 
set  the  WI75.  Of  course,  if  a  real  look-through  with 
measurements  were  carried  out,  ihe  controller  should 
handle  the  off  timing  in  order  to  know  w  hen  to  make 
the  measurements;  the  W175  example,  though, 
would  be  an  easy  way  to  simulate  such  behavior. 

Second,  suppose  a  test  design  requires  a  very  small 
noise  spot  (one  smaller  than  the  residual  modulation 
when  the  noise  generator  attenuator  is  set  as  7  or  full 
attenuation).  The  fill  oscillator  output  alone  could  be 
used,  but  not  if  good  noise  characteristics  are  needed. 
The  user  could  get  a  small  spot  with  noise  character¬ 
istics  by  using  the  fm  W 1 75  as  a  noise  source. 


The  user  would  first  program  the  RAM  blocks  to 
contain  random  Y  values  in  the  range  -127  to  +  127. 
This  can  be  done  easily  with  a  simple  for/next  output 
loop.  For  best  results,  all  four  RAM’s  would  be  pro 
grammed,  though  fewer  could  be  used.  An  example 
of  setting  up  the  four  I  M  W175  RAM’s  for  noise 
is: 

fori  -  8  to  1 1:  wrt  701,  “C",  1,  "I” 

for  J  =  0  to  255 

wrt  701 ,  “X”,  J,  “Y",  -  127  +  254  rnd  ( 1 ) 

next  J;  next  1. 

The  W 1 75  noise  spot  can  then  be  used  by  calling 
“swpl75”  with  the  desired  spot  bandwidth  as  the 
frequency  deviation  and  with  the  maximum  block 
rate  (7.8  kHz  for  RAM),  specifying  the  RAM 
block(s)  in  which  the  noise  data  were  stored. 

Noise  data  could  also  be  specified  to  meet  desired 
characteristics  conditions,  such  as  Gaussian  noise, 
filtered  noise,  and  so  on.  The  user  may  wish  to  pro¬ 
gram  PROM’s  to  hold  noise  data;  this  would  allow 
the  noise  to  be  set  up  with  a  19.5  kHz  block  rate 
rather  than  a  7.8  kHz  rate.  The  highest  possible  block 
rate  is  desirable  in  order  to  most  closely  simulate  a 
noise  source. 

This  brings  up  a  closing  point  applicable  when  the 
W 175  is  used  for  fm.  The  voltage-frequency  data  in 
the  W$  calibration  tables  (see  Appendix  E)  are  taken 
from  operator  measurements  during  a  run  of  the  cali¬ 
bration  program.  That  program  uses  the  W175  sine 
block  at  a  19.5  kHz  rate.  This  gives  an  output  shape 
that  is  easy  to  measure  on  a  spectrum  analyzer  dis¬ 
play. 

It  has  been  noticed  that  when  the  fm  W175  data 
are  used  to  set  up  an  fm  sweep  at  much  lower  block 
rates  (such  as  I  Hz),  the  sweep  bandwidth  will  differ 
somewhat  from  what  it  would  be  at  higher  rates  even 
though  the  voltage  is  the  same.  An  empirical  rule  to 
quantize  this  effect  has  not  yet  been  worked  out. 
When  a  rule  is  found,  it  will  be  included  in  a  modi¬ 
fied  version  of  “swpl75.”  At  present,  it  is  up  to  the 
user  to  check  on  and  allow  for  the  bandwidth  rate 
effect. 
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APPENDIX  I 

USER  DOCUMENTATION 


The  user  should  document  any  newly  written  test 
program.  Documentation  will  allow  others  besides 
the  original  user  to  read,  understand,  and  modify  a 
program.  It  will  also  make  it  easier  for  the  original 
user  to  modify  the  program,  especially  if  some  time 
elapses  between  writing  and  modifying.  Good  docu¬ 
mentation  makes  it  easier  to  use  subroutines  and  pro¬ 
cedures  from  one  test  program  in  other  programs  and 
so  can  save  time  in  the  long  run.  In  addition,  docu¬ 
mentation  provides  a  means  of  recovering  a  test  pro¬ 
gram  in  the  event  that  all  taped  copies  of  that  pro¬ 
gram  are  lost,  destroyed,  or  found  unreadable. 

Documentation  might  range  from  little  more  than 
a  program  listing  with  notes  to  a  full  formal  report. 
How  much  effort  the  user  puts  into  documenting  any 
test  report  will  depend  on  the  user’s  perception  of 
the  test’s  importance,  its  usefulness  as  a  source  of 
material  for  other  tests,  and  the  identity  of  the  test’s 
potential  users  (additionally,  in  practice  the  amount 
of  time  the  user  has  for  documenting  tests  would  be  a 
major  factor). 

At  the  least,  documentation  should  always  include 
an  outline  of  what  the  program  does,  identification 
of  what  the  variables  used  stand  for,  and  a  program 
listing.  This  much  could  all  fit  on  the  same  paper.  A 
listing  can  be  taken  on  the  HP9825’s  internal  printer 
and  the  printer’s  paper  tape  saved  by  fastening  it  to 
sheets  of  notepaper,  with  the  program  outline  indi¬ 
cated  through  program  mnemonic  label  names  (see 
Appendix  D)  and  variable  use  notes  pencilled  next  to 
the  listing. 

This  much  documentation,  which  can  be  done  in 
very  little  time,  is  suitable  for  the  personal  use  of  the 
original  user  who  wrote  the  program.  It  is  not  really 
suitable  for  use  by  others  but  would  be  quite  accep¬ 
table  for  a  simple  program  operated  by  the  original 
user.  Its  advantage  is  that  it  can  be  quickly  prepared 
from  material  the  user  would  prepare  anyway  and  so 
does  not  require  any  noticable  additional  effort  or 
time  from  the  user. 

It  may  be  appropriate  to  point  out  here  that  the 
HP9825’s  internal  printer  is  a  thermal  dot  matrix 
printer,  using  treated  paper.  The  printing  will  fade 
with  time,  especially  if  left  exposed  to  strong  light 
and  heat  (if  the  printer  paper  is  attached  to  notepaper 
with  cellophane  tape,  any  printing  under  the  tape  will 


fade  much  more  rapidly).  With  any  program  listing 
kept  more  than  a  few  weeks,  it  would  be  a  prudent 
measure  to  copy  the  listing  to  a  less  perishable 
medium.  Photocopying  works  well. 

A  listing  with  a  note-type  of  documentation  is 
what  the  user  would  prepare  for  personal  reference. 
A  more  detailed  documentation  effort  is  needed 
when  a  test  program  will  be  read  and  modified  by- 
others  than  the  original  user.  Better  documentation  is 
also  desirable  when  a  program  is  very  long  or  very 
complex,  or  when  it  might  serve  as  a  source  of  sub¬ 
routines  and  procedures  for  use  in  other  programs. 
More  extensive  documentation  than  the  basic  listing 
with  notes  would  be  valuable  if  a  program  is  modi¬ 
fied  after  it  was  written,  even  if  that  program  is  oper¬ 
ated  and  modified  by  the  original  user. 

Such  documentation  can  range  from  what  would 
be  a  listing  with  expanded  notes  to  a  formal  report 
with  an  operator’s  guide.  As  a  rule,  informal  docu¬ 
mentation  should  be  quite  acceptable  if  the  program 
will  be  run  by  the  original  user,  or  by  a  few  operators 
who  can  be  shown  through  the  program  by  the 
original  user  and  who  can  directly  ask  that  user  any 
questions  that  arise  while  running  the  test  program. 

A  formal  report  would  be  called  for  if  a  test  pro¬ 
gram  will  be  run  by  several  operators,  or  when  the 
program  will  be  used  outside  the  facility  where  it  was 
prepared,  or  when  a  test  would  be  used  for  some  time 
(this  last  is  a  key  point  since  the  original  user  may  not 
always  be  readily  available  to  explain  a  program). 

In  such  cases,  it  would  be  more  efficient  for  the 
original  user  to  prepare  formal  documentation  once, 
rather  than  explaining  a  program  to  each  new  opera¬ 
tor  or  to  each  new  user  wanting  to  modify  the  pro¬ 
gram.  Formal  documentation  implies  a  more  detailed 
account  of  what  a  progam  does,  such  as  giving  a  de¬ 
scription  of  any  algorithms  or  calculations  in  the 
user’s  program.  Formal  documentation  would  also 
include  an  operator’s  guide  detailing  the  responses 
and  options  available  to  an  operator. 

The  form  of  user  documentation  may  vary 
according  to  what  each  user  feels  best  meets  the  needs 
for  a  program.  It  is  possible,  however,  to  suggest  a 
standard  form  for  formal  documentation.  A  stan¬ 
dard  form  would  have  advantages  in  that  it  would 
give  the  documentation  reader  an  idea  of  what  the 
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reader  can  expect  to  find  in  the  documentation.  It 
would  also  save  the  user  a  little  time  and  effort  since 
the  user  would  not  have  to  devise  a  new  torm  lor 
each  documentation  report. 

Informal  documentation  can  use  elements  of  the 
same  standard  form,  dropping  some  sections, 
abridging  and  combining  others.  By  doing  so.  the 
user  makes  it  easier  to  upgrade  from  informal  to 
formal  documentation  if  the  need  arises. 

The  suggested  standard  form  for  documentation  is 
made  up  of  1 1  sections,  which  are  described  in  the  re¬ 
mainder  of  this  appendix.  The  standard  form  outline 
is: 

1 .  Statement  of  test  purpose, 

2.  Interval  form/  time  behavior, 

3.  Operator  inputs, 

4.  Fault  recovery, 

5.  Tape  use, 

6.  User  subroutines. 

7.  Operator’s  guide, 

8.  Variable  use, 

9.  Miscellaneous  information, 

10.  Detailed  description,  and 

11.  Listings. 

The  statement  of  test  purpose  can  be  a  single 
paragraph  identifying  the  program’s  name  and  its 
purpose.  The  program  name  should  be  given  as  a 
label  on  line  0  to  help  identify  the  program  when  it  is 
loaded  in  the  controller  or  listed. 

The  interval  form/time  behavior  identifies  the  test 
output  as  a  function  of  time  (see  Appendix  B).  This 
will  inform  the  reader  what  the  test  program  does 
and  identify  output  changes  and  what  controls  the 
timing  and  nature  of  the  changes  (such  as  a  program- 
fixed  change  or  one  selected  by  the  operator). 

Operator  inputs  would  be  a  list  of  what  the 
operator  can  affect  in  the  program.  It  is  not  an 
operator’s  guide  (see  below)  but  more  of  an 
information  source,  letting  the  reader  know  what  an 
operator  can  enter  and  something  of  when  and  how 
entries  are  made,  but  leaving  details  to  the  user’s 
guide.  This  would  be  on  the  level  of  “the  operator 
may  specify  frequency  centers  and  noise  spots  before 
the  output  begins  by  replying  to  controller 
prompts.” 

Fault  recovery  would  explicitly  tell  an  operator 
how  to  recover  from  a  simulator  crash,  whether  due 
to  the  subroutine  blocks  (“err  stp”)  or  the  control¬ 
ler  (“shutoff”).  The  user  might  provide  a  suitable 
label  at  some  part  of  the  program  and  inform  the 
operator  that  the  program  could  be  continued  at  that 


label  if  a  fauli  stops  the  program  (e.g..  the  operatot 
might  type  and  execute  something  like  'com 
“restart”  see  Appendix  1).  This  part  of  formal 
documentation  may  also  summarize  how  to  fix  am 
faults  that  might  be  expected  in  the  test  involved, 
such  as  specifying  too  large  a  deviation  range  at  some 
point. 

Tape  use  should  identify  the  tape  files  needed  b> 
the  program  being  documented.  There  will  be  at  least 
the  program  file  itself;  there  may  also  be  data  files, 
function  key  files,  seperately  taped  interval  segments, 
and  help  files.  All  such  user  files  should  be  identified, 
giving  track  and  file  numbers.  If  the  subroutine 
blocks  (or  a  subset  of  the  subroutine  blocks)  are 
loaded  into  the  controller  during  the  program,  the 
track  and  file  numbers  for  the  blocks  should  also  be 
identified.  This  part  of  a  formal  documentation 
report  lets  users  and  operators  know  what  tape  files 
are  needed  and  where  those  files  should  be  on  tape.  A 
list  of  tape  files  and  purposes  would  usually  be  ac¬ 
ceptable,  making  this  a  formal  version  of  the  infor¬ 
mation  that  the  user  might  note  on  the  paper 
returned  by  the  tlist  instruction  and  kept  with  the 
tape  cartridge  (see  Appendix  G).  The  operator  can 
also  be  told  when  to  remove  a  tape  cartridge  and 
reminded  to  rewind  tapes  before  removing  them. 

User  subroutines  can  be  listed  by  giving  their  label 
names  and  parameter  lists,  with  a  brief  account  of 
their  purpose  (as  is  done  for  the  subroutine  blocks  in 
Appendix  N).  This  would  provide  a  handy  reference 
if  a  latter  user  wanted  to  see  if  any  of  the  program's 
subroutines  could  be  lifted  for  use  in  a  different  pro¬ 
gram.  If  good  mnemonic  label  names  were  given  to 
the  user’s  subroutines,  this  part  of  a  formal  docu¬ 
mentation  could  also  indirectly  give  a  short  outline  of 
the  program  structure. 

An  operator’s  guide  would  take  an  unfamiliar  op¬ 
erator  through  all  the  steps  required  to  get  the  test 
program  running.  It  treats  all  parts  of  a  program  visi¬ 
ble  to  and  requiring  responses  from  the  operator.  It 
can  give  more  detailed  information  than  will  fit  into 
operator  prompts  as  part  of  a  program  (see  Appendix 
D).  This  part  of  a  formal  documentation  would  begin 
by  specifying  what  tape  file  to  load  in  order  to  start 
the  test  program;  it  would  then  identify  each  opera¬ 
tor  input,  giving  the  input’s  purpose,  range,  and 
default  value,  if  any  (see  Appendix  C).  The  reader 
would  be  told  what  conditional  next  steps  would 
follow  each  branch  control  question.  A  reader  should 
be  able  to  go  through  the  operator’s  guide  of  a 
formal  documentation  report  and  find  out  before 
running  the  lest  what  the  response  would  be  to  any 
input  entry.  A  good  account  of  the  default  values  (set 
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by  pressing  CONTINUE  after  a  prompt  without 
entering  anything)  would  be  particularly  useful.  The 
user  may  find  the  operator  response  format  used  in 
the  HP9825  Utilities  Program  reference  book  to  be  a 
useful  model. 

Variable  use  would  identify  the  purpose  the  user 
assigns  to  the  global  variables  (p-numbers  within  a 
user-written  subroutine  can  be  described  as  part  of  a 
detailed  description;  see  below).  The  user  should 
identify  what  each  variable  is  used  for,  how  the  vari¬ 
ables  are  set  up,  and  what  changes  take  place  and 
when.  If  arrays  or  strings  are  used  to  hold  data,  the 
user  should  identify  the  overall  purpose  of  the  array 
or  string  and  its  internal  structure  (e.g.,  if  A  [  *  1  is 
used  to  hold  parameter  values,  the  user  states  so  and 
also  lists  the  purpose  of  each  element  in  A[*|).  If 
any  data  are  prepared  and  taped  in  advance  of  a  test, 
the  user  should  state  how  to  prepare  those  data  and 
where  to  tape  them. 

Miscellaneous  information  is  a  catch-all  for  any 
points  the  user  thinks  could  be  useful  for  the  opera¬ 
tor  to  know.  Examples  would  be  the  use  of  the  func¬ 
tion  keys  in  a  test,  notes  on  timing  or  accuracy  con¬ 
straints,  possible  program  modifications,  suggested 
test  values,  and  output  monitoring  suggestions. 

A  detailed  description  of  the  user’s  program 
would  be  used  chiefly  by  anyone  who  wants  to  modi¬ 
fy  the  program.  The  detailed  description  would  go 


through  the  user’s  program  and  account  for  each  in¬ 
struction  and  statement.  It  would  describe  the  pro¬ 
gram’s  structure,  its  algorithms,  and  branching 
decisions;  detail  the  timing  control;  and  give  the  pur¬ 
pose  of  user  provided  subroutine  p-numbers.  This 
detailed  description  can  be  organized  to  match  a  pro¬ 
gram’s  structure.  If  a  program  is  structured  as  a 
number  of  subroutine  calls,  the  detailed  description 
can  first  describe  how  the  calls  are  made  and  how  the 
passed  parameters  are  found,  and  then  separately 
describe  the  user  provided  subroutines.  A  detailed 
description  would  be  the  most  time-consuming  part 
of  preparing  a  formal  documentation  report. 

A  copy  of  the  user  program  listing  would  be 
included  in  a  formal  documentation,  possibly  as  an 
appendix.  This  listing  provides  insurance  against  all 
tape  copies  of  a  program  being  lost.  In  case  of  such  a 
loss,  the  program  could  be  retyped  from  the  listing 
(inasmuch  as  such  typing  can  be  remarkably  tedious, 
the  user  is  again  urged  (as  in  Appendix  G)  to  make 
backup  tape  copies  of  all  programs  used  more  than 
once).  The  user  will  probably  prepare  a  listing  with  a 
note-type  of  documentation  as  an  interim  measure 
when  writing  and  debugging  a  long  or  complex  test 
program;  this  can  be  directly  copied  (after  any  cor¬ 
rections)  as  the  program  listing,  which  would  make 
the  notes  readily  accessible  to  anyone  reading  the 
listing. 
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APPENDIX  J 


INITIALIZATION  STATUS 


After  the  simulator  power  is  turned  on  and  the 
multiprogrammer  completes  a  self-test,  the  simulator 
will  be  in  the  state  shown  in  Table  J-l.  In  particular, 
in  each  ri  channel  the  pulse  modulator  is  turned  on, 
the  biphase  circuit  adds  a  20  MHz  comb,  the  fill  os¬ 
cillator  is  off,  there  is  no  output  power  level  attenua¬ 
tion,  and  the  VCO  select  circuit  may  be  ambiguously 
connected.  Also,  the  states  of  the  FM  and  am 
auxiliary  switch  matrices  are  not  definitely  set  but 
may  wake  up  randomly,  and  the  data  format  of  vari¬ 
ous  multiprogrammer  output  cards  is  not  that  re¬ 
quired  by  the  subroutine  blocks.  The  result  is  that  the 
simulator  is  in  an  ambigous  state  and  its  output  con¬ 
sists  of  spurious  signals.  This  result  will  also  hold 
whenever  the  “clear  bus”  message  is  sent  from  the 
controller,  except  that  the  auxiliary  switch  matrices 
are  not  changed  from  their  previous  states. 


The  “initial”  subroutine  will  remove  the 
spurious  outputs  and  ambiguous  conditions  and  put 
the  multiprogrammer  cards  into  the  data  format 
needed  by  the  subroutine  blocks.  After  “initial”  is 
called,  there  will  be  no  simulator  outputs.  All 
modulators  are  off,  attenuators  arc  set  to  full 
attenuation  (this  includes  output  power  level),  and  all 
switches  are  turned  off.  The  subroutine  will  also 
intitialize  Z  |  *  ]  and  print  the  current  calibration  data 
identification  on  the  HP9825’s  internal  printer. 
Before  calling  “initial”,  Z  [  *  J  and  U$  must  be 
dimensioned. 

Once  “initial”  is  called,  the  user  may  proceed  to 
build  up  a  test  modulation  from  a  known  starting 
point  (see  Table  J-l)  and  can  rely  on  the  multipro¬ 
grammer  cards  accepting  the  subroutine  block  data 
format. 


TableJ-1  -  Initialization. 
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APPENDIX  K 


SUBROUTINE  BLOCK  MODIFICATIONS 


There  are  a  number  of  recommended  modifi¬ 
cations  that  could  be  made  to  the  subroutine  blocks 
as  they  exist  as  of  October  1981.  These  modifications 
fall  into  three  categories.  First,  some  modifications 
could  be  made  to  improve  the  usefulness  and  struc¬ 
ture  of  the  subroutine  blocks.  These  would  serve  to 
improve  the  existing  subroutine  block  software. 
Second,  some  modifications  could  be  made  by  a  user 
for  a  particular  test;  such  modifications  are  test  spe¬ 
cific.  Third,  some  could  be  made  to  extend  the  sub¬ 
routine  blocks'  capabilities,  especially  by  modifying 
a  one-VCO  run  type  subroutine  to  cover  several 
VCOs.  These  are  extension  modifications.  For  clari¬ 
ty.  each  of  these  three  modification  types  is  discussed 
under  a  separate  subheading. 

Improvement 

Some  modifications  could  be  made  to  make  the 
subroutine  blocks  easier  to  use  and  understand.  None 
of  these  modifications  is  actually  required,  but  some 
will  be  made  in  the  future  to  obtain  their  particular 
benefits. 

When  checking  frequency  limits,  the  subroutines 
might  obtain  the  numbers  from  Z$,  using  VCO 
number  as  an  index  and  the  num  function  to  obtain 
the  actual  numbers  (which  must  be  scaled  to  hertz 
units).  This  would  be  longer  and  slower  than  the 
present  use  of  limits  calculated  from  the  band 
number  but  would  let  the  limits  represent  the  actual 
achievable  hardware  limits  (though  this  would  com¬ 
plicate  the  calibration  program  since  its  operator 
would  then  have  to  indicate  when  the  output  does  be¬ 
come  clipped).  It  would  also  free  the  limit  checks 
from  a  dependence  on  having  a  particular  type  of  rf 
channel  in  a  particular  slot.  It  should  be  noted,  how¬ 
ever,  that  while  on  paper  this  would  better  match  the 
statement  that  the  MMG  ECM  simulator  channels 
are  interchangeable,  it  is  not  clear  that  in  practice 
that  interchangableness  extends  to  removing  one 
channel  out  of  the  rack  and  replacing  it  with  a  differ¬ 
ent  channel  type  for  one  test.  Removing  an  rf 
channel  requires  removing  a  number  of  screws  and 
connections;  it  is  easier  to  leave  the  channels  where 
they  are.  When  the  type  III  RF  channels  are  added, 
such  a  change  may  be  needed. 


A  few  changes  are  recommended  for  the 
“fnoise”  subroutine  blocks.  Given  its  length,  it 
may  be  desirable  to  divide  it  into  two  or  three  subrou¬ 
tines  in  order  to  make  it  easier  to  read.  For  example, 
the  instructions  that  find  attenuator  settings  from  the 
fill  and  noise  spots  could  be  separated. 

Aside  from  breaking  up  its  length,  a  user  may  wish 
to  modify  the  details  of  how  “fnoise”  actually  gets 
an  attenuator  value.  Presently  the  subroutine  looks 
through  the  data  for  attenuator  settings  from  1  to  7 
and  tries  to  find  the  first  data  entry  less  than  the 
desired  output.  If  found,  “fnoise”  will  use  the  pre¬ 
vious  attenuator  value  (0-6);  if  not.  it  will  use  7.  As 
familiarity  with  the  simulator  is  acquired,  it  can  be 
determined  whether  this  method  gives  acceptable  re¬ 
sults;  if  not,  the  process  can  be  modified.  For  ex¬ 
ample,  the  subroutine  might  look  through  0  to  6,  use 
the  present  attenuator  value  rather  than  the  previous 
one  (especially  if  it  looks  through  0-6  rather  than  I- 
7),  check  for  “  less  than  or  equal  to"  rather  than 
“less  than,”  or  report  a  fault  if  the  desired  spot  is 
less  than  the  full  attenuation  value. 

Two  modifications  could  be  made  to  “swpi75," 
both  of  which  would  be  useful.  First,  the  instructions 
that  calculated  the  WI75  voltage  based  on  the  VCO 
and  the  desired  frequency  deviation  could  be  split  off 
into  a  separate  subroutine  (which  might  be  called 
“voltswp”  or  “voltl75”).  This  separate  subrou¬ 
tine  could  then  be  called  by  the  user’s  program 
whenever  the  user’s  program  wanted  to  check  if  a 
W175  frequency  deviation  was  legal  (at  present  this 
must  be  done  by  directly  manipulating  data  entries, 
which  is  awkward  and  requires  fair  knowledge  of  the 
data  setup).  This  would  be  particularly  useful  when 
checking  operator  inputs. 

Second,  the  check  of  the  W175  block  rate  high 
limit  could  be  conditionally  tied  to  the  function 
number  to  distinguish  between  RAM  and  ROM  or 
PROM  blocks  (see  Appendix  FI).  This  type  of  modi¬ 
fication  could  also  be  made  to  “AMPS.” 

If  a  simple  empirical  relation  can  be  found  between 
the  frequency  deviation  at  high  rates  and  at  low  rates 
(see  Appendix  H),  that  relation  could  be  worked  into 
“swpl75.”  Whether  this  is  done  depends  on  what 
magnitude  the  rate  effect  is  found  to  have  in  practice 
and  what  sort  of  empirical  relation  is  noticed. 
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It  may  be  found  desirable  in  practice  to  extend 
"load.XS”  to  allow  video  filter  values  (as  well  as 
numbers)  to  be  passed.  It  may  also  be  desirable  to 
prepare  a  single  subroutine  that,  when  called,  would 
call  all  three  “load-S”  subroutines  using  the  same 
VCO  number. 


Test  Specific 

The  user  will  occasionally  find  it  useful  to  make 
some  subroutine  block  modifications  as  part  of  a 
particular  test.  Such  modifications  would  be  used 
only  in  the  test  in  which  they  are  needed.  It  is  impor¬ 
tant  that  the  user  keep  track  of  such  modifications, 
especially  when  the  modified  subroutine  blocks  are 
separately  taped.  It  will  be  up  to  the  user  to  avoid 
confusing  the  modified  blocks  with  the  original  ones. 
Good  tape  documentation  will  help. 

Probably  the  most  likely  lest  specific  modification 
would  involve  “enter.”  If  a  test  allows  operator  en¬ 
tries  and  does  not  expect  any  operator  entries  having 
"milli-”  units  (i.e.,  no  milliseconds  likely),  then  it 
may  be  desirable  to  modify  “enter”  so  that  “meg- 
a”  units  (i.e.,  MHz)  can  be  entered  with  either  an 
upper-  or  lower-case  character,  as  is  the  case  with 
“giga”  or  “kilo-”  units.  This  can  be  done  by 
deleting  the  small  m  line  in  “enter”  and  adding  the 
cap  function  to  the  large  M  line  so  that  M  is  treated 
similarly  toG  or  K. 

If  this  change  is  made,  it  will  save  the  operator 
some  effort  and  make  it  easier  to  enter  values  w  ithout 
making  mistakes.  The  operator  should  be  told  thai  a 
small  m  will  specify  "mega-”,  either  in  the  docu¬ 
mentation  or  as  part  of  the  program’s  initializa¬ 
tion. 

If  it  is  found  that  this  change  is  widely  used  in 
practice,  it  might  be  made  a  permanent  modification 
similar  to  the  improvement  modifications  described 
earlier.  It  might  be  done  as  a  permanent  modification 
anyway,  so  that  an  operator  would  not  have  to  te- 
member  if  a  large  or  small  letter  M  will  do  in  a  partic¬ 
ular  program. 

Other  changes  are  less  likely  to  be  considered  per¬ 
manent.  If  the  user  wants  flag  14  set  throughout  the 
user’s  program,  the  clear  flag  14  instructions  in  vari¬ 
ous  subroutine  blocks  could  be  deleted  (see  Appendix 
E). 

If  space  is  short,  the  subroutine  blocks  could  be 
abridged  somewhat  by  cutting  some  of  the  checks 
(such  as  the  VCO  number  checks).  This  should  be 
done  with  care  since  any  erroneous  parameters 


(which  are  more  likely  in  a  long,  complex  program) 
could  then  lead  to  undetected  error  conditions.  It 
would  generally  be  bet t  -r  to  use  a  subset  of  the  sub¬ 
routine  blocks  (loading  only  those  needed)  or  a  multi¬ 
interval  with  separately  taped  segments. 

The  user  may  on  occasion  also  wish  to  change  the 
error  branching  to  allow  use  of  defaults  without 
crashing  the  program.  This  is  acceptable  if  it  is  done 
as  a  test-specific  modification,  with  any  such  defaults 
being  reported  (for  example,  by  printing  a  notice  on 
the  HP9825’s  interval  printer). 

Some  of  the  calls  are  not  always  necessary 
and  could  theoretically  be  cut  to  save  space,  but  it  is 
generally  safer  to  leave  this  call  intact. 

Modifications  to  the  run  type  subroutine  blocks 
can  be  carried  out  through  the  nextval  subroutines  if 
only  the  output  values  are  involved.  More  extensive 
modifications  are  covered  below. 


Extension 

Some  modifications  can  serve  to  extend  the  capa¬ 
bilities  of  the  subroutine  blocks.  These  extensions 
may  be  modifications  within  the  framework  of  the 
existing  subroutine  blocks,  or  they  may  involve  such 
modifications  as  to  create  new  ones.  The  latter  par¬ 
ticularly  applies  to  creating  new  run  type  subroutines 
by  building  on  and  modifying  an  existing  one. 

The  first  group  of  extensions  would  involve  a 
number  of  desirable  features  that  might  wait  until  the 
controller  is  upgraded  and  more  memory  space  be¬ 
comes  available.  Notably,  the  subroutines  can  be  set 
up  to  keep  track  of  the  data  in  the  controller  and  up¬ 
date  then  as  necessary.  A  number  of  variables  could 
be  dedicated  for  use  as  flags,  perhaps  by  extending 
Z  ( *  J  or  using  a  newly  dimensioned  Y ( *  J ;  initial 
values  would  be  set  by  “initial.” 

The  extended  software  would  primarily  involve 
“setVC'O”  and  “fnoise”  tracking  the  VCO  num¬ 
bers  and  video  filters  in  use.  The  “load-$”  subrou¬ 
tines  would  be  called  as  needed  when  either  the  active 
VCO  in  an  Rt  channel  or  the  video  filter  is  used  lot 
noise  changes.  However,  there  may  be  cases  in  which 
the  user  might  not  want  to  spend  the  time  needed  to 
change  the  data  (see  near  the  end  of  this  appendix). 
In  such  cases,  the  user  would  have  to  bypass  or  dis¬ 
able  any  automatic  data  updating. 

The  other  subroutines  might  be  extended  so  that 
when  they  are  called  they  must  be  called  with  an 
active  VCO  number.  Subroutine  blocks  that  affect 
the  tune  centers  or  noise  spot  bandwidths  can  be 
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given  common  global  variable  references  that  can  be 
checked  to  prevent  illegal  combinations,  such  as  a 
.TOO  MHz  noise  spot,  legally  set  on  a  3.2  GHz  center, 
being  moved  to  a  new  2.0  GHz  center.  Checks  could 
be  built  in  to  preve  t  a  W175  set  as  an  fm  source 
from  being  connected  to  a  pulse  circuit. 

While  such  extensions  would  remove  some  of  the 
subroutine  block  independence,  the  extensions  would 
also  increase  the  confidence  that  the  simulator  will 
always  be  in  a  legal  state.  Such  extensions  would  slow 
down  the  subroutine  block  execution  time  and  in¬ 
crease  the  required  memory  size  by  whatever  is 
needed  for  the  additional  instructions  and  the  data 
used  to  hold  the  checked  values.  It  remains  to  be  de¬ 
termined  if  such  extensions  are  really  needed  or  use¬ 
ful;  such  determination  can  be  put  off  until  such  time 
as  the  controller  is  upgraded,  giving  more  time  in 
which  to  gain  familiarity  with  the  simulator  and  a 
better  idea  of  what  extensions  would  really  be  use¬ 
ful. 

The  second  group  of  extensions  involves  modi¬ 
fying  run  type  subroutines  to  get  new  subroutines. 
This  sort  of  extension  can  be  carried  out  whenever 
needed.  With  time,  a  library  of  run  type  subroutines 
can  be  built  up,  and  the  user  would  select  only  the 
ones  needed  for  a  test. 

It  should  again  be  noted  that  if  a  run  type  subrou¬ 
tine  needs  only  a  different  set  of  output  values,  the 
subroutine  can  be  modified,  assuming  it  uses  a  next- 
val  approach,  by  simply  changing  the  nextval  (see 
Appendix  D).  If  the  subroutine  does  not  use  a  nextval 
approach  (i.e. ,  “ownswp”),  it  would  be  rewritten 
to  use  a  different  means  of  getting  its  values  (e.g.,  in 
“ownswp"  one  could  change  the  triangular  wave¬ 
form  to  a  sawtooth  ramp  by  simply  deleting  one  of 
the  two  inner  X  loops). 

The  most  obvious  case  in  which  the  user  may  wish 
to  modify  and  extend  a  subroutine  block  would  arise 
when  the  user  wants  a  one-VCO  run  pattern  to  run 
on  several  VCOs  simultaneously.  The  user  can  extend 
the  single  VCO  subroutine.  How  this  is  done  will 
depend  on  whether  the  VCOs,  running  simultan¬ 
eously,  share  control  cards  and  whether  the  indi¬ 
vidual  VCOs,  running  simultaneously,  change  syn¬ 
chronously  or  asynchronously. 

Generally,  if  the  modulations  of  several  VCOs 
share  control  cards,  the  changes  must  be  connected 
through  holding  words;  if  there  are  no  common 
cards,  the  changes  can  be  taken  independently.  For 
example,  if  tune  centers  are  changed,  the  user  must 
remember  that  two  VCOs  are  controlled  by  one  tune 
card.  Here  the  user  must  avoid  accidentally  wiping 
out  one  tune  word  of  a  pair  when  changing  the  other 


(unless  the  RF  channel  controlled  by  that  tune  word  is 
not  in  use).  This  can  be  done  as  in  "stepmod." 
Instead  of  sending  out  the  new  value  directly,  it  is 
manipulated  by  binary  operations  to  fit  in  an  internal 
word,  and  that  internal  word  (which  also  contains  the 
data  for  the  rest  of  the  card)  is  sent  out.  On  the  other 
hand,  the  am  D/A  cards  are  independent,  so  values 
for  those  cards  can  be  handled  separately. 

In  extending  a  run  type  subroutine  block  (or 
writing  a  new  one),  the  user  must  determine  if  the  in¬ 
dividual  sources  change  synchronously  or  asynchro¬ 
nously,  and  if  asynchronously,  if  the  rates  are  the 
same  or  different.  All  but  the  last  can  be  handled  in  a 
fairly  straightforward  way. 

If  the  sources  in  a  multiple  source  run  type  subrou¬ 
tine  change  synchronously,  all  of  the  new  data  is  sent 
over  the  bus  at  the  same  time,  using  the  “output  par¬ 
allel”  (OP)  instruction.  The  desired  output  rate  can 
be  set  with  a  single  controller  wait  instruction. 

It  should  be  noted  that  the  user  cannot  specify  the 
same  card  slot  address  twice  in  the  same  OP  instruc¬ 
tion.  If  two  of  the  synchronous  changes  are  con¬ 
trolled  by  the  same  card,  they  must  be  combined 
before  (or  as  part  of)  the  OP  instruction. 

If  the  sources  in  a  multiple  source  run  change  asyn¬ 
chronously  but  all  at  the  same  rate,  the  new  data  can 
be  sent  out  using  a  series  of  OS  instructions  and 
waits.  Each  wait  (offset  by  a  loop  time)  is  set  to  re¬ 
flect  the  relative  timing  between  each  asynchronous 
change,  subject  to  the  constraint  that  the  sum  of  all 
the  individual  waits  (offset  by  all  of  the  loop  times) 
must  match  the  overall  dwell  implied  by  the  asyn¬ 
chronous  rate.  Since  the  rates  are  all  the  same,  the 
relative  liming  between  sources  will  be  fixed.  The 
user  must  specify  the  order  and  relative  timing  of  the 
source  changes. 

It  should  be  noted  that,  for  the  asynchronous 
changes,  the  loop  time  that  should  offset  the  wait  be¬ 
tween  one  adjacent  pair  of  changes  will  not  neces¬ 
sarily  be  the  same  as  that  for  other  pairs.  Whether  it 
is  or  not  will  depend  on  the  details  of  the  output 
loop.  If  a  loop  is  set  up  to  get  all  the  values  for  one 
pass  of  the  loop  and  then  sequentially  sends  them 
out,  the  loop  time  between  the  last  output  of  one  pass 
and  the  first  of  the  next  pass  would  be  somewhat 
greater  than  the  loop  time  for  pairs  within  the  same 
pass.  An  asynchronous/single  rate  loop  could  also  be 
set  up  so  that  it  sequentially  gets  a  value,  sends  it  over 
the  bus,  and  waits;  in  this  case  the  loop  times  between 
any  adjacent  pair  should  be  the  same  (assuming  the 
same  amount  of  time  spent  getting  each  value),  but 
the  loop  time  may  increase. 
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Which  approach  is  used  for  an  asynchronous/ 
single  rate  loop  is  up  to  the  user.  It  might  be  slightly 
easier  to  keep  track  of  tabled  values  if  all  values  for 
one  pass  are  collected  at  the  same  lime.  Of  the  two 
approaches,  the  former  is  belter  suited  for  rippling 
all  the  source  changes  close  together  in  time,  with  a 
longer  time  to  the  next  set  of  changes,  since  it  would 
give  the  shortest  loop  time  between  changes  within 
one  pass.  Unless  it  takes  very  long  to  get  all  change 
values,  the  former  approach  should  also  be  satisfac¬ 
tory  for  patterns  in  which  the  changes  are  more  sym¬ 
metrically  timed  (i.e.,  roughly  equal  times  between 
any  two  changes,  including  the  last  of  one  pass  and 
•he  first  of  a  following  pass);  if  it  does  take  too  much 
time  to  get  all  the  values,  the  user  could  first  consider 
a  different  way  of  getting  those  values,  such  as  calcu¬ 
lation  in  advance  of  the  output  run,  with  the  output 
values  being  held  in  an  array. 

On  the  other  hand,  it  would  be  somewhat  easier  to 
determine  the  loop  time  offset  when  each  asynchro¬ 
nous  value  is  found  separately,  since  then  only  one 
loop  time  need  be  found  rather  than  two  or  more. 
However,  getting  all  the  loop  values  for  one  pass  at 
the  same  time  will  save  overhead  time  by  reducing  the 
number  of  times  the  loop  must  get  a  value.  Also,  it  is 
not  difficult  to  roughly  estimate  how  much  time  each 
step  in  the  loop  should  take.  These  estimates  would 
then  be  refined  by  measuring  the  actual  output 
dwells. 

Some  early  simulator  observations  give  rough  esti¬ 
mates  for  the  maximum  synchronous  and  asynchro¬ 
nous  output  rates.  Based  on  changing  three  Rf- 
channels  and  using  data  calculated  and  tabled  in  ad¬ 
vance  of  the  output  loop,  the  maximum  synchronous 
output  rate  is  about  26.3  Hz.  The  maximum  asyn¬ 
chronous/single  rate  output  rate  is  around  12.5  Hz, 
but  this  could  possibly  be  improved  to  about  16.5 
Hz,  since  the  12.5  Hz  estimate  was  made  with  a 
simple  loop  in  which  shift  operations  were  carried 
out  during  the  loop  rather  than  in  advance  of  the 
run. 

It  would  be  more  difficult  to  run  independent 
modulations  at  the  same  time,  which  is  what  asyn¬ 
chronous  changes  at  different  rates  would  be.  The 
order  in  which  the  sources  involved  change  will  vary 
and  the  time  between  changes  will  vary.  Some  of  the 
different  rates  may  be  multiples  of  some  common 
base,  leading  to  an  occasional  coincidence  of  changes 
for  several  of  the  sources. 

In  order  to  simulate  asynchronous/different  rates 
output,  the  user  must  be  able  to  specify  the  order  of 
source  changes  and  the  relative  time  between  changes 
as  functions  of  time.  This  will  in  general  be  difficult. 


but  if  it  can  be  done  the  controller  can  run  the  asyn¬ 
chronous/different  rates  output. 

Whenever  possible,  the  user  should  try  to  tie  sever¬ 
al  of  the  rates  to  a  common  base;  the  source  changes 
run  at  those  rates  could  then  be  defined  in  terms  of 
their  common  output  period.  In  other  words,  if  some 
overall  repeat  pattern  can  be  found,  then  the  output 
can  be  organized  in  terms  of  that  pattern.  This  is 
easiest  if  all  the  sources  running  are  involved  in  the 
repeat  pattern.  Finding  a  repeat  pattern  would  be  the 
most  straightforward  approach  to  simulating  an 
asynchronous/different  rates  output,  but  finding  a 
repeat  pattern  (if  one  exists)  can  be  tedious  and  diffi¬ 
cult;  if  the  repeat  period  is  very  long,  an  explicit  use 
of  that  period  may  require  too  much  space  and  effort 
to  be  practical. 

Most  generally,  the  user  could  try  to  devise  some 
algorithm  to  describe  at  each  output  step  which 
source  changes,  what  value  it  changes  to,  and  how 
much  time  elapses  to  the  next  change. 

The  same  sort  of  subroutine  could  handle  the 
actual  running  regardless  of  how  the  user  actually  de¬ 
fines  the  outputs.  Basically  the  subroutine  would  de¬ 
termine  how  many  output  changes  to  run;  then  for 
each  output  it  must  determine  an  address  (which 
specifies  the  source  that  changes),  a  value,  and  a 
wait.  These  values  could  be  found  using  a  nextval 
subroutine,  where  the  nextval  contains  the  user’s 
definition  of  the  output  pattern.  Any  necessary 
checks  or  data  manipulations  (such  as  binary  shifts 
and  word  combinations)  should  be  done  within  the 
nextval  and  can  be  tied  to  the  nextval’s  determina¬ 
tion  of  the  source  or  address.  The  basic  form  of  the 
main  subroutine  can  be  outlined  as: 

determine  N  (number  of  changes) 
tor  index  =  1  to  N 
call  nextval:  determine 

address,  value,  time 
write  multiprogrammer:  address,  value 
wait  (time  -  offset) 
next  index. 

This  can,  of  course,  be  modified  as  the  user  sees 
fit.  It  would,  for  instance,  need  modification  if  any 
sources  change  simultaneously  (perhaps  by  using  a 
conditional  jump).  Also,  each  pass  of  the  output 
loop  might  determine  several  address,  value,  and 
time  sets  and  output  them,  with  the  loop  index  being 
changed  to  reflect  the  number  of  sets  in  each  pass. 

The  maximum  asynchronous/different  rates  out¬ 
put  rate  will  depend  on  the  number  of  sources  and 
how  complex  the  sequence  determination  proves,  but 
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it  might  be  expected  to  be  fairly  low  in  practice,  with 
any  individual  source  likely  being  limited  to  around  5 
Hz  when  all  sources  have  comparable  rates.  At  the 
time  this  is  written,  no  measured  asynchronous/ 
different  rates  measurements  are  available  to  check 
the  estimated  rate  limit. 

Summarizing  what  has  been  said  so  far  about  the 
extension  of  the  run  type  subroutines:  When  ex¬ 
tending  a  single  VCO  run  type  subroutine  to  handle 
several  VCOs,  the  user  must  determine  if  the  run  type 
modulation  sources  are  changed  synchronously  or 
asychronously;  if  the  latter,  the  user  must  determine 
if  the  outputs  are  all  changed  at  the  same  rate  or  with 
different  rates.  With  asynchronous  changes,  the  user 
must  specify  the  order  in  which  the  sources  change 
and  the  relative  timing  between  changes. 

Other  extensions  could  be  made  for  single  VCO 
subroutines  (these,  of  course,  might  then  be  extended 
to  several  VCOs).  Two  examples  can  be  given 
readily.  First,  the  user  can  write  a  subroutine  to  gen¬ 
erate  an  FM  signal  through  the  FM  D/A  in  the  multi¬ 
programmer  extender  by  exploiting  the  obvious  simi¬ 
larities  with  the  am  D/A’s.  This  might  be  called 
“FMown”  and  would  be  an  analog  of 
“AMown,”  just  as  “AMaux”  is  an  analog  of 
“auxmod.” 


Second,  suppose  a  test  called  for  sweeping  a  noise 
spot  from  a  type  II  RF  channel  between  I  and  3  GHz 
(this  assumes  the  1-2  GHz  VCOs  would  by  then  be 
available).  The  controller  could  run  such  a  pattern  in 
a  manner  analogous  to  that  used  in  "ownswp." 
The  sweep  would  start  with  one  VCO  active  and  the 
controller  would  move  the  tune  center  along  its  sweep 
pattern  (whatever  that  happened  to  be)  until  it 
reached  the  2  GHz  value  that  separates  the  two  VCO 
bands.  The  controller  would  then  set  the  tune  center 
of  the  inactive  VCO  to  the  limit  value  of  2  GHz  and 
then  switch  the  active  VCO  in  the  rf  channel.  The 
sweep  would  then  continue.  The  necessary  D/A 
numbers  should  be  found  in  advance  so  that  the  data 
need  not  be  updated  during  the  run  of  the  sweep. 
(The  noise  spot  could  be  expected  to  change  notice¬ 
ably  during  such  a  sweep  across  VCO  unless  it  were 
reset  at  a  few  representative  points  along  the  sweep; 
this  would  require  the  data  to  be  updated,  slowing 
down  the  sweep). 

The  basic  point  of  this  part  of  the  appendix  is  that 
when  a  new  run  type  output  is  wanted  the  user  does 
not  have  to  start  from  scratch  but  can  save  much  time 
and  effort  by  building  upon  the  existing  subroutines, 
modifying  them  to  suit  the  new  requirements.  The 
actual  nature  of  the  modifications  will  depend  on  the 
needs  of  the  user. 
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APPENDiX  L 


PROGRAM  CHECKLIST 


The  actual  instructions  that  make  up  a  test  pro¬ 
gram  will  vary  widely,  depending  on  the  nature  of  the 
test  and  the  way  a  user  chooses  to  write  that  test. 
However,  some  basic  steps  are  common  to  every  test 
program,  as  described  in  Appendix  B.  This  appendix 
gives  a  brief  summary  and  checklist  of  a  few  of  those 
steps,  specifically  those  needed  to  get  any  output 
from  the  simulator. 

The  simulator  must  be  initialized:  strings  and 
arrays  must  be  dimensioned,  subroutine  blocks 
loaded  (if  not  already  part  of  the  program  file), 
“initial”  called,  data  loaded,  and  so  on  (see  Appen¬ 
dix  B).  When  the  program  is  ready  to  create  an  out¬ 
put  signal,  it  must  ensure  that  the  right  VCO  in  an  rf 
channel  is  active  and  call  “setVCO”  if  it  is  not 
active  (“initial”  will  set  the  B  labeled,  or  higher  fre¬ 
quency,  VCO  in  each  RF  channel  as  the  active  VCOs). 
The  program  must  then  ensure  that  the  biphase  and 
pulse  carriers  are  set.  If  no  biphase  (or  pulse)  modu¬ 
lation  has  been  set  for  an  rf  channel,  the  carrier 
should  be  turned  on.  The  tune  center  might  be  ad¬ 
justed  so  that  the  output  will  be  in  the  response  range 
of  that  VCO  (the  wake-up  D/A  number  of  zero  will 
in  some  cases  give  a  severely  clipped  output  that  is 
out  of  the  VCOs  range).  Finally,  the  output  power 
level  should  be  adjusted  from  its  post-“initial” 
value  of  8 1  dB  of  attenuation. 


There  is  no  fixed  order  for  carrying  out  these  es¬ 
sential  steps  (after  initialization,  which  is  the  first 
step),  but  they  must  be  done  directly  or  indirectly  if 
any  output  signal  is  actually  to  be  found  at  the  simu¬ 
lator’s  output  ports.  Some  steps  can  be  done  indi¬ 
rectly;  for  example,  setting  a  20  MHz  biphase  comb 
will  turn  on  the  biphase  carrier,  and  setting  a  noise 
spot  through  “fnoise”  with  a  center  frequency  as 
the  fourth  passed  parameter  will  set  the  tune  cen¬ 
ter. 

The  following  short  list  can  be  used  as  a  pro¬ 
gramming  checklist  to  ensure  that  the  essential  steps 
have  been  carried  out. 

1.  Initialization 

2.  Set  active  VCO 

a.  Implicit  after  “initial”  if  VCO 
number  is  even 

b.  Explicit  (“setVCO")  if  VCO  number  is 
odd.  Update  data. 

3.  Turn  carriers  on 

a.  Pulse 

b.  Biphase 

4.  Set  tune  center  0/  A  number 

5.  Output  power  level  (“ampset”) 
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APPENDIX  M 

MISCELLANY 


This  appendix  contains  a  miscellany  of  notes  and 
suggestions  that  may  be  useful  but  that  are  not  in 
themselves  important  enough  or  long  enough  to  justi¬ 
fy  separate  appendixes. 

Memory  Size 

The  15  October  1981  version  of  the  subroutine 
blocks  requires  9970  bytes  of  the  HP9825  con¬ 
troller's  22,910  available  bytes,  or  roughly  44%  of 
ihe  available  memory.  Unneeded  subroutines  can  be 
cut  in  a  particular  program  to  reduce  the  amount  of 
required  space:  the  size  of  each  subroutine  is  given  in 
Appendix  K  (the  total  of  individual  sizes  does  not 
match  the  combined  size  due  to  storage  overhead). 
The  variables  and  data  used  by  the  subroutine  blocks 
require  about  3.5K  (15%)  of  the  controller  memory. 
The  subroutine  blocks  could  use  about  1 3.5K  (59%) 
of  the  controller  memory  if  the  full  subroutine  block 
set  is  used.  This  leaves  about  9.4K  bytes  for  the  us¬ 
er’s  program  and  data. 

Subroutine  Block  Placement 

The  subroutine  blocks  may  be  loaded  in  any  part 
of  the  controller  memory;  there  is  no  dependence  on 
specific  line  numbers.  Typically  the  user  will  write  a 
program  and  add  the  subroutine  blocks  to  the  end  of 
the  test  program.  If  a  separately  taped  segment  ap¬ 
proach  is  used,  it  may  be  easier  to  load  the  subroutine 
blocks  first  and  add  the  program  segments  below  the 
blocks.  If  this  is  done,  line  0  should  have  an  uncon¬ 
ditional  go  to  branch  to  a  label  identifying  the  start 
of  the  user’s  program;  otherwise,  pressing  RUN  (or 
CONTINUE  after  a  reset  or  editing)  will  lead  to  an 
execution  error  as  the  controller  tries  to  run  the  sub¬ 
routine  blocks  as  if  they  were  mainline  programs. 

f-Kcys 

The  HP9825  has  a  number  of  user-definable 
special  function  keys  or  f-keys  (keys  for  short).  The 
keys  work  as  part  of  the  live  keyboard,  do  not  give  an 
interrupt  capability,  cannot  be  used  to  call  a  function 


or  subroutine,  or  use  the  ent  statement  in  live  key¬ 
board. 

The  keys  may  be  used  during  and  as  part  of  a  test 
program.  Uses  might  include  reading  the  multipro¬ 
grammer  clock  and  printing  the  values  of  some  speci¬ 
fied  variables.  The  keys  may  run  a  for/ next  loop  but 
should  never  use  as  the  loop  index  any  variable  also 
used  in  the  test  program. 

The  keys  can  also  be  used  to  change  the  value  of  a 
variable  by  assignment  of  a  new  value.  This  feature 
might  be  used  as  a  way  of  letting  an  operator  rapidly 
change  the  rate  of  a  run  type  output  during  a  test;  the 
output  loop  wait  time  would  be  assigned  to  a  simple 
variable,  and  a  number  of  possible  values  for  that 
variable  could  be  held  in  the  keys;  two  keys  might  be 
set  up  to  increment  and  decrement  that  variable  value 
by  some  fixed  amount  each  time  those  two  keys  are 
used.  The  feature  can  also  be  used  to  allow  an  opera¬ 
tor  to  control  branching:  The  program  would  set  a 
variable  to  zero,  then  on  a  separate  line  use  a  prompt 
message  followed  by  a  jump  of  that  variable,  the  keys 
assigning  non-zero  values  to  the  variable.  For 
example,  the  program  might  be: 

0  — A 

dsp  “select  key”;  jmp  A 
gto  “first” 
gto  “second,” 

while  the  keys  would  be: 

fO:  *  1  —  A  fl:  *  2— A 

The  user  will  also  find  the  keys  helpful  when  typing 
a  long  program  into  the  controller.  Frequently  used 
statements  or  combinations  of  characters  can  be 
stored  in  the  keys  (without  the  immediate  execute  as¬ 
terisk)  and  the  keys  used  to  add  the  stored  phases  to 
the  line  being  typed.  The  key  contents  do  not  have  to 
be  complete  statements  or  meaningful  in  themselves. 
For  example,  when  typing  in  a  program  that  handles 
a  number  of  operator  entries,  two  keys  would  be: 

fO:  “”  — U$;  ent” 

fl:  “,  US  f  I,  32];  if  fig  13. 

Using  the  keys  as  a  typing  aid  can  greatly  reduce 
the  workload  of  typing  a  long  program. 
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Fill  On  Noise  Spots 

This  has  been  covered  before  (see  Appendix  E)  but 
can  bear  separate  emphasis.  The  “fnoise”  subrou¬ 
tine  block  will  divide  an  rf  channel’s  desired  noise 
spot  RF  bandwidth  into  a  part  taken  from  the  rf 
channel’s  fill  oscillator  and  a  part  taken  from  the 
noise  generator.  The  fill  is  used  to  square  off  the 
spot’s  edges.  Nominally,  20°7o  of  the  desired  spot  is 
generated  by  the  fill  oscillator,  with  the  remainder 
coming  from  the  noise  generator. 

The  fill  can  be  used  alone  (noise  generator  off)  by 
calling  “fnoise”  with  an  explicit  video  number  of 
zero.  The  user  (or  operator)  can  change  the  fraction 
of  a  spot  that  “fnoise”  will  get  from  the  fill  oscilla¬ 
tor  by  changing  the  contents  of  X  [5  ]  from  its  normal 
value  of  0.2  to  some  other  fraction  before  “fnoise” 
is  called.  The  fraction  should  be  in  the  range  0  to  1 .  A 
0  will  set  the  fill  oscillator  to  full  attenuation,  leaving 
just  the  noise  generator  as  the  spot  source.  A  1  is  not 
equivalent  to  passing  a  video  number  of  zero,  since 
the  1  would  set  the  noise  generator  to  full  attenuation 
but  leave  it  on. 

How  the  value  of  X  [5  ]  (and  hence  the  fraction  of 
a  spot  generated  by  the  fill  oscillator)  is  varied  is  up 
to  the  user  or  operator.  X  [5 )  can  be  changed  from 
the  live  keyboard;  “fnoise”  must  be  called  before  a 
change  in  X  [5  ]  will  take  effect. 


Interrupts 

The  user  is  reminded  that  the  bus  interrupt 
handling  capabilities  of  the  HP9825  provide  a  power¬ 
ful  way  for  the  controller  to  monitor  the  actual  status 
of  the  simulator.  At  present  this  capability  is  not  used 
and  no  simulator  devices  will  actually  interrupt  the 
controller,  but  the  user  should  not  forget  about  this 
capability.  Interrupts  could  be  particularly  useful  if 
the  simulator  is  modified  and  extended  to  include 
measurement  devices  to  allow  a  closed  loop  moni¬ 
toring  of  the  simulator  by  the  controller.  The  user 
should  consult  the  HP9825  reference  manuals  (espe¬ 
cially  the  manual  for  the  extended  I/O  ROM)  for  de¬ 
tails  on  handling  interrupts. 


Bus  Device  Status 

This  item  is  related  to  the  above.  The  user  should 
not  forget  the  possible  uses  of  the  bus  device  status 


line.  The  bus  status  is  explicitly  read  by  the  controller 
(e.g.,  rds  7,  rds  723).  It  would  be  particularly  useful 
in  cases  where  the  program  sets  up  some  bus  device  to 
do  some  slow  or  variable  duration  task  and  the  pro¬ 
gram  should  do  one  set  of  procedures  while  waiting 
for  the  task  to  finish  and  another  set  after  the  finish. 
If  the  device  sets  the  SRQ  line,  the  status  can  be  mon¬ 
itored  to  see  when  it  is  set.  The  HP9825  and  6942 
(multiprogrammer)  reference  manuals  can  be  con¬ 
sulted  for  suggested  uses  and  examples. 

Timeouts 

The  user  may  find  the  “time”  function  of  the 
HP9825  controller  useful  if  the  simulator  is  extended 
by  the  addition  of  measurement  devices.  The 
“time”  function  allows  a  specified  time  for  an  I/O 
device  to  complete  before  “time”  will  cause  an 
error.  This  could  be  used  to  check  for  damaged  de¬ 
vices  (those  that  fail  to  respond).  It  can  also  be  used 
in  conjunction  with  the  on  error  branching  of  the 
controller  to  provide  some  alternate  action  if  no  I/O 
reply  is  made  within  a  specified  time.  Several 
“time”  periods  could  be  looped  to  get  longer 
periods  by  using  the  on  error  branch  and  a  counter. 
The  on  error  branch  would  replace  or  supplement  the 
one  that  enables  “shutoff”.  At  present  only  the 
controller’s  keyboard  could  be  considered  an  I/O 
device  suitable  for  use  with  “time,”  but  it  is 
unlikely  that  this  feature  will  be  used  much. 
However,  it  could  be  used  to  optionally  allow 
operator  changes  between  intervals  of  a  program, 
with  some  default  arranged  if  no  reply  is  made  within 
some  time  period. 

The  user  can  also  extend  the  timing  control  of  the 
simulator  by  using  the  n.ultiprogrammer  real-time 
clock,  and  the  multiprogrammer  wait  instructions 
can  be  useful  in  special  cases  such  as  when  several 
multiprogrammer  instructions  are  passed  in  the  same 
controller  write  instruction. 

Bus  Additions 

The  simulator  can  be  expanded  through  the  addi¬ 
tion  of  new  bus-compatible  devices.  Such  devices  can 
be  given  any  available  device  addresses  on  bus  7  at 
first  (see  Table  H-l).  Up  to  three  additional  bus  lines 
could  be  added  to  the  controller’s  interface  (if  the  in¬ 
terface  slots  are  not  used  for  some  other  purpose), 
but  it  is  rather  unlikely  that  this  would  be  necessary 
to  get  more  device  addresses  than  are  available  on 
bus  7.  Additional  bus  lines  could  be  added  if  inter- 
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rupt  capable  measurement  devices  are  added;  by 
selecting  a  bus  number  higher  or  lower  than  7,  the 
user  could  control  the  interrupt  priorities. 

Lockouts 

The  controller  may  use  the  lockout  ( 1 1  o)  command 
to  prevent  a  device  on  the  simulator’s  bus  from 
being  modified  from  the  device’s  front  panel  (see 
Appendix  H  for  a  discussion  of  this  in  connection 
with  the  W175s).  The  user  would  generally  lock  out 
bus  devices  when  they  are  being  set  and  used  by  the 
controller,  in  order  to  prevent  undetected  status 
changes  that  could  lead  to  faulty  program  results. 

The  user  could  also  lock  out  the  controller’s  live 
keyboard  by  disabling  it  (lkd),  though  this  is  not  rec¬ 
ommended  because  it  would  keep  the  operator  from 
using  the  controller  as  a  calculator  during  a  test  run, 
would  prevent  the  use  of  the  function  keys,  and 
would  keep  the  operator  from  checking  variable 
values.  Disabling  the  keyboard  may  seem  attractive 
as  a  way  of  keeping  the  operator  from  crashing  a  pro¬ 
gram  by  ill-advised  keyboard  changes,  but  if  an  oper¬ 
ator  wants  to  crash  a  program  the  operator  can  al¬ 
ways  find  a  way.  It  seems  better  to  allow  the  operator 
free  use  of  the  live  keyboard  because  it  can  improve 
the  workload  of  a  knowledgeable  operator  and  dis¬ 
abling  it  would  not  keep  an  unknowledgeable  one 
from  finding  a  way  to  crash. 

For/Next  Loop  Indices 

It  can  make  a  user’s  program  easier  to  read  if  a 
consistent  use  of  variables  is  maintained  throughout 
a  test  and  between  different  tests.  A  suggestion  in  this 
line  is  that  the  for/next  loops  use  the  variables  1  and  J 
as  the  main  indices,  with  K,  M,  or  N  being  used  if 
more  than  two  for/next  loops  are  stacked  (X  and  Y 
are  used  in  the  subroutine  blocks).  Q  could  be  re¬ 
served  for  live  keyboard  for/next  loops. 

The  user  must  avoid  stacking  for/next  loops  in 
such  a  way  that  an  inner  loop  and  an  outer  loop  have 
the  same  variable  as  the  index.  This  includes  cases  in 
which  the  inner  loop  is  part  of  a  subroutine  called  by 
the  outer  loop. 

Flags 

Flags  0-12  are  freely  available.  These  are  useful  for 
status  indicators  and  branch  or  condition  indicators, 
especially  when  such  indicators  are  passed  from  one 
user  subroutine  or  program  segment  to  another. 


HP6942  Outputs 

It  will  be  noted  that  most  of  the  subroutine  block 
multiprogrammer  outputs  are  by  single  output  in¬ 
structions.  This  keeps  each  multiprogrammer  output 
independent  and  increases  the  user’s  flexibility  in 
combining  subroutines.  However,  only  a  fraction  of 
the  multiprogrammer’s  power  is  used,  since  it  can 
accept  a  number  of  instructions  in  one  write  output 
by  the  controller.  It  is  difficult  to  use  this  power  gen¬ 
erally  since  the  subroutine  blocks  (or  other  user- 
written  independent  subroutines)  do  not  generally 
know  in  advance  what  combination  of  multipro¬ 
grammer  instructions  will  follow.  In  a  run  type  sub¬ 
routine,  the  instructions  are  known  but  not  neces¬ 
sarily  the  number  of  instructions  or  all  of  the  instruc¬ 
tion  data;  hence  it  is  much  easier  to  handle  the  output 
one  instruction  at  a  time.  The  user  should  keep  the 
multiprogrammer’s  multiple  instruction  capability 
in  mind  and  may  find  a  use  for  it. 

It  should  be  noted  that  if  multiple  multipro¬ 
grammer  instructions  are  sent  from  the  controller  in 
one  write  instruction,  then  the  distinction  between 
the  multiprogrammer’s  serial  mode  (GS)  and 
parallel  mode  (GP)  becomes  important  (the  multi¬ 
programmer  is  in  serial  mode  after  “initial”).  The 
HP6942  reference  manual  can  be  consulted  for 
details  and  examples. 


For/Next  Line  Breakup 


If  the  HP9825’s  STOP  key  is  pressed  while  the 
controller  is  running,  the  program  will  stop  when  the 
end  of  the  current  line  is  reached.  There  will  be  times 
when  the  operator  will  want  to  stop  a  for/next  loop 
briefly  and  then  go  on  with  it  by  pressing 
CONTINUE.  For  example,  during  a  run  type  output 
(such  as  a  hoping  noise  spot),  the  operator  may  want 
to  stop  the  run  long  enough  to  check  the  signal  being 
changed  (e.g.,  to  look  at  the  spot  being  hopped). 

If  a  for/next  loop  is  written  so  that  it  is  entirely  on 
one  line,  then  that  loop  must  complete  before  a 
STOP  interrupt  will  take  effect.  It  would  be  a  good 
programming  practice  to  break  every  for/next  loop 
so  that  the  loop  is  on  at  least  two  lines.  An  exception 
might  be  made  when  space  is  short  and  the  loop  is 
known  to  be  short  (few  passes  and  little  time  per 
pass).  An  exception  is  also  made  for  for/next  loops 
run  by  the  live  keyboard,  which  must  of  course  be 
one  line.  If  stop  is  pressed  during  a  live  keyboard 
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for/next  loop,  the  loop  will  run  through  to  its  end  at 
a  high  rate  regardless  of  any  wait  times  written  in  the 
loop  (such  waits  would  be  bypassed).  A  live  keyboard 
for/ next  loop  that  is  stopped  by  the  operator  cannot 
be  continued  after  the  stop. 


“?”  Position 

The  “?”  subroutine  block  is  used  to  check  the 
multiprogrammer’s  busy  instuction  register  (see  Ap¬ 


pendix  O).  It  should  be  included  in  any  user-written 
run  type  subroutines.  Since  it  lakes  some  time  to  exe¬ 
cute  this  subroutine,  it  would  be  a  good  pro¬ 
gramming  practice  to  put  this  subroutine  in  toward 
the  end  of  a  for/next  loop  rather  than  directly  after 
the  write  instruction.  Thus,  the  multiprogrammer  in¬ 
struction  could  ..omplete  while  any  other  loop  in¬ 
structions  (such  a  wait)  are  carried  out;  then,  when 
“?”  is  called  it  will  not  have  to  wait  for  the  multi¬ 
programmer  (at  least  it  would  not  have  to  wait  as 
long).  The  arrangement  of  "AMown"  (see  Appen¬ 
dix  Q),  provides  an  example  of  positioning  “?" 
properly. 
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APPENDIX  N 


SUBROUTINE  BLOCKS,  ONE-LINE  DESCRIPTION 


1 .  ?  (bit  number,  word  number) 

Checks  status  of  HP6942  busy  instruction 
register  and  waits  until  instruction  specified  by 
parameters  is  complete. 

2.  fval  #  (VCO  number,  center  frequency) 

Finds  the  D/A  code  number  corresponding  to 
the  passed  frequency  and  returns  it  in  W. 

3.  fset  (VCO  number,  center  frequency) 

Sets  the  passed  frequency  on  the  specified 
VCO. 

4.  fnoise  (VCO  number,  spot  rf  BW,  video  filter 
number/BW,  band  part) 

Sets  in-channel  noise  of  specified  VCO.  If  spot 
not  given,  or  given  as  zero,  will  turn  off  noise. 
Band  part  may  be  given  as  numbers  1-3  (low, 
mid,  or  high  band)  or  as  frequency  (in  the  latter 
case,  this  will  set  that  frequency  as  the  center) 
or  may  dt  tult  as  mid  band.  Video  filter  may  be 
given  as  a  filter  number  or  a  bandwidth  value. 
An  explicit  video  number  of  zero  will  turn  the 
noise  generator  off  but  leave  the  fill  oscillator 
on  to  provide  the  requested  spot. 

5.  pulse  (VCO  number,  source  number) 

Selects  the  modulation  source  switched  into  the 
pulse  circuit. 

6.  biph  (VCO  number,  source  number) 

Selects  the  modulation  source  switched  into  the 
biphase  circuit. 

7.  auxmod  (VCO  number,  source  number) 
Switches  the  coded  modulation  source  through 
the  auxiliary  fm  switch  matrix  to  the  specified 
VCO. 

8.  AMaux  (VCO  number,  source  number) 

Switches  the  coded  modulation  source  through 
the  auxiliary  am  switch  matrix  to  the  specified 
VCO. 

9.  ampset  (VCO  number,  dB  attenuation) 

Sets  the  output  power  amplitude  reference  level 
in  dB  down  from  maximum  output. 

10.  AMown  (VCO  number,  rate,  number  points) 
Uses  controller  and  required  “AMval”  user 
routine  to  run  am  through  D/A  cards  in 
HP6943. 

11.  set  VCO  (VCO  number) 

Selects  the  active  VCO  in  the  appropriate  rf 
channel. 


12.  initial 

Initializes  the  simulator  status. 

13.  stepmod  (VCO,  number  points) 

Uses  controller  and  required  “stepval”  and 
“stepwt”  user  routines  to  run  an  arbitrary 
modulation  pattern  through  the  tune  card. 

14.  ownswp  (VCO  number,  low  frequency,  high 
frequency,  rate,  number  sweep) 

Uses  the  controller  to  run  a  triangle  D/A 
number  sweep  on  the  given  VCO. 

15.  swpl75  (VCO  number,  center  frequency,  fre¬ 
quency  deviation,  block  rate,  function 
number) 

Sets  up  the  fm  arbitrary  waveform  generator  to 
provide  a  frequency  deviation  about  the  center, 
which  is  set  on  the  appropriate  tune  card. 

16.  AM175  (VCO  number,  maximum  dB  attenua¬ 
tion,  block  rate,  function  number) 

Sets  the  am  arbitrary  waveform  generator  to 
modulate  the  power  amplitude  of  the  VCO 
output. 

17.  DC175  (%  duty  cycle,  period,  W175  number, 
VCO  numbers.  .  .) 

Sets  up  either  of  the  arbitrary  waveform  gener¬ 
ators  as  a  pulse  source  for  up  to  six  VCOs. 

18.  T/P  (period,  VCO  number.  .  .) 

Sets  up  the  timer/pacer  card  as  a  pulse  source 
for  up  to  six  VCOs. 

19.  special  (band  number,  rate,  running  time,  table 
length) 

Uses  the  controller  and  required  "valspec” 
user  routine  to  synchronously  change  the  out¬ 
puts  of  all  VCOs  in  the  band. 

20.  err  stp 

Disables  simulator  when  other  subroutines  de¬ 
tect  an  illegal  condition. 

21.  shutoff 

Disables  simulator  when  controller  detects  an 
error.  Must  be  itself  enabled  to  be  in  effect. 

22.  enter 

Subroutine  function.  Will  convert  an  aphanu- 
meric  operator  entry  to  numeric  form. 

23.  inRFid 

Subroutine  function.  Will  ask  operator  for  rf 
number  and  VCO  as  A  or  B,  and  return  VCO 
number. 
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24.  loadW$  (VCO  numbers.  .  .) 

loadXS  (VCO  number,  video  filter  number, 
VCO  number.  .  .) 
loadYS  (VCO  numbers.  .  .) 

These  subroutines  will  load  data  from  the  stan¬ 


dard  tape  format  to  controller  memory  for 
W175,  noise,  and  fill,  respectively.  Up  to  six 
VCOs  (or  VCO/filter  number  pairs)  may  be 
specified. 
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APPENDIX  O 

SUBROUTINE  BLOCKS,  SHORT  REFERENCE 


This  appendix  briefly  summarizes  the  main  charac¬ 
teristics  of  each  subroutine  block.  Included  in  each 
description  are  lists  of  the  variables  and  data  used, 
notes  on  the  parameter  ranges,  and  a  brief  descrip¬ 
tion  of  the  subroutine  block’s  purpose.  The  form  of 
each  description  is  indicated  in  Table  0-1.  Two 
points  should  be  noted  about  the  descriptions.  Under 
“variables  used,”  the  listed  p-number  is  the  highest 
numbered  one  used,  and  all  lower  p-numbers  are  also 
allocated.  Flag  14  will  be  set  and  cleared  by  each  sub¬ 
routine  block  unless  “no  flag  14”  is  noted. 

I .  ?  (bit  number,  word  number) 

Size:  56  bytes 
Parameter  ranges: 

bit  number:  0-15  (integer) 
word  m  nber.  1, 2 
Subroutines  used:  none 
Variables  used:  p4;  no  flag  14 
Data  used:  none 
Error  code:  none 

Table  0-1  -  Short  reference  form. 

Label  (parameter  list) 

Size:  number  of  bytes 
Parameter  ranges: 

Parameter  number  I :  range  number  t 


Subroutines  used  :  list 
Variables  used  list 

Data  used  list 

Error  codes  case  number 

cause  number  -  cause 


Notes: 

Short  description  '■  subroutine 

The  “?”  subroutine  block  is  used  to  avoid  timing 
problems  with  the  multiprogrammer  (mD).  The  mp 
may  have  only  one  active  instruction  of  a  specific 
type  at  any  time.  Thus,  for  example,  if  an  OS  output 
instruction  is  being  executed  when  a  second  OS 


instruction  is  sent  from  the  controller  to  the  mp,  the 
second  OS  would  be  lost.  This  subroutine  will  read 
the  mp  busy  instruction  register  until  the  instruction 
bit  specified  by  the  passed  parameters  is  unset,  in¬ 
dicating  that  the  instruction  has  completed.  “?” 
should  be  called  whenever  an  output  loop  repeatedly 
uses  the  same  mp  instruction.  It  may  also  be  called  in 
nonloop  cases  as  a  general  precaution.  For  easy 
reference,  the  bit  and  word  numbers  for  the  output 
serial  (OS)  and  output  parallel  (OP)  are: 

OS:  4,  I 

OP:  2,  1 


2.  fval#  (VCO  number,  f„) 

Size:  406  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
f.i :  f„„„  -  fma*(Hz) (cf.  Table  C-2) 
Subroutines  used:  none 
Variables  used:  p9,  V,  W  (return);  no  flag  14 
Data  used:  Z$ 

Error  code:  2 

number  0-f„  less  than  f,.„n 
number  l-f0  greater  than  fmav 
number  2-D/A  number  out  of  bounds 
The  “fval#”  subroutine  block  is  used  to  find  the 
D/ A  converter  number  corresponding  to  the  passed 
frequency  and  to  return  that  number  through  the 
variable  W.  The  D/A  number  is  found  by  linear 
interpolation  from  the  tune  data  held  in  ZS.  “fval#” 
does  not  affect  flag  14. 


3.  fsei  (VCO  number,  f„) 

Size:  268  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
f<>:  fmm  -  f™, (Hz)  (cf.  Table  C-2) 
Subroutines  used:  fval#,  ? 

Variables  used:  p5,  Z  [ *  J,  W  (indirect:  V) 
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Data  used:  Z[*  1  (indirect:  Z$) 

Error  code:  1 

number  0  -  illegal  VCO  number  passed 
The  “fset”  subroutine  block  is  used  to  set  the 
passed  tune  center  frequency  on  the  specified  VCO. 


4.  fnoise  (VCO  number,  spot  RF  BW,  video 
number  or  BW,  band  part) 

Size:  1316  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 

spot  BW:  0-f„„„(Hz)  (cf.  Table  C-2  and 

below) 

video  BW:  0-5  (integer)  (cf.  Table  E-3) 

or:  (IK,  10K,  100K,  1M,  5M)(Hz) 
band  part:  1  (low),  2  (mid),  3  (high),  or 
f  min  -  fn,.,(Hz) 

(if  not  given,  defaults  to  mid 
band;  see  below) 

Subroutines  used:  ?,  fset  (indirect:  fval#) 
Variable  used:  pl6,  Z[*  1 ,  X (indirect:  V,  W) 
Data  used:  X$,  Y$,  X  [5],  Z[*  ]  (indirect:  Z$) 
Error  code:  5 

number  0  -  illegal  VCO  number  passed 
number  1  -  spot  rf  BW  out  of  range 
number  2  -  illegal  video  filter  passed 
number  3  -  band  part  frequency  out  of  band 
number  4  -  spot  rf  BW  cannot  be  achieved 
(greater  than  0  dB  attenuation  width) 
Interior  label:  fnout 

The  ''fnoise”  subroutine  block  is  used  to  set  the 
passed  noise  spot  on  the  specified  VCO  from  the  in¬ 
channel  noise  and  fill  sources.  The  noise  spot  is 
specified  by  the  rf  bandwidth,  the  video  filter,  and 
the  part  of  the  band  in  which  the  signal  lies  (band 
part). 

The  subroutine  will  turn  off  the  noise  spot  if  zero  is 
passed  as  the  spot  rf  BW.  The  same  effect  would  be 
had  if  the  subroutine  were  called  with  only  the  VCO 
number  passed.  Legal  nonzero  spot  RF  BW’s  must 
meet  the  following  conditions: 
f0  -  Af/2  <  =  fmin 
f„  +  Af/2  <  =  fmax 

Af  is  identical  with  the  spot  rf  BW,  and  f„  is 
determined  by  the  passed  band  part  parameter  (if  this 
last  parameter  is  not  passed,  it  will  default  to  mid¬ 
band).  If  band  part  is  passed  as  a  number  (1,  2,  or  3), 
f„  will  be: 

f„  =  (1.2  +  0.3  (number  -  I))  fmin 

If  band  part  is  passed  as  a  frequency  (any  number 


not  1,  2,  or  3),  that  frequency  will  be  used  as  f„. 
Moreover,  in  this  last  case  the  subroutine  will  call 
“fset”  to  set  the  tune  center  frequency. 

Video  noise  filters  1  through  5  correspond  to 
actual  filters  from  1  kHz  to  5  MHz.  A  video  filter  of 
zero  corresponds  to  turning  off  the  noise  generator 
while  leaving  the  fill  oscillator  on;  this  is  desirable 
when  very  small  spots  are  wanted  (though  the 
resulting  spot  would  have  fill  oscillator,  not  noise, 
characteristics).  A  video  filter  number  of  zero  must 
be  passed  explicitly. 

The  software  will  check  that  a  passed  spot  rf  BW 
is  greater  than  zero  and  less  than  the  bandwidth  of 
the  VCO;  the  actual  hardware  limits  will  vary  and 
will  be  more  restrictive. 


5.  pulse  (VCO  number,  source  number) 

Size:  232  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
source  number:  0-7  (integer)  (cf.  Table  C-l) 
Subroutines  used:  ? 

Variables  used:  p3,  Z  [  *  ] 

Data  used:  Z  ( *  ] 

Error  code:  3 

number  0  -  illegal  VCO  number  passed 
number  1  -  illegal  source  number  passed 
The  “pulse”  subroutine  block  is  ust '.  to  select  the 
modulation  source  connected  to  the  passed  VCO 
through  the  pulse  modulation  circuit.  The  source 
numbers  and  sources  are: 

0  -  carrier  on 

1  -  10  Hz,  50%  square  wave 

2  -  100  Hz,  50%  square  wave 

3  -  W175  (A) 

4  -  W175  (B) 

5  -  timer/pacer  card 

6  -  external 

7  -  carrier  off 


6.  biph  (VCO  number,  source  number) 

Size:  230  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 

Source  number:  0-7  (integer)  (cf.  Table  C-l) 
Subroutines  used:  ? 

Variables  used:  p3,  Z  [  * ) 
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Data  used:  Z  ( *  | 

Error  code:  4 

number  0  -  illegal  VCO  number  passed 
number  1  -  illegal  source  number  passed 
The  “biph”  subroutine  block  is  used  to  select  the 
modulation  source  connected  to  the  passed  VCO 
through  the  biphase  modulation  circuit.  The  source 
numbers  and  sources  are: 

0  -  20  MHz  comb 

1  -  10  MHz  comb 

2  -  5  MHz  comb 

3  -  carrrier  on 

4  -  40  MHz  biphase  noise 

5  -  20  MHz  biphase  noise 
6-10  MHz  biphase  noise 
7  -  carrier  off 


7.  auxmod  (VCO  number,  source  number) 

Size:  300  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 

source  number:  0-3  (integer)  (cf.  Table  C-l) 
Subroutines  used:  ? 

Variables  used:  p2,  Z  [  12 ) 

Data  used:  Z  [121 
Error  code:  6 

number  0  -  illegal  VCO  number  passed 

number  1  -  illegal  source  number  passed 
The  “auxmod”  subroutine  block  is  used  to  select 
the  modulation  source  connected  to  the  passed  VCO 
through  the  FM  auxiliary  switch  matrix.  The  source 
numbers  and  sources  are: 

0  -  off 

1  -  external 

2  -  D/A  FM 

3  -  W175  (B) 


8.  AMaux  (VCO  number,  source  number) 

Size:  292  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
source  number:  0-3  (integer)  (cf.  Table  C-l) 
Subroutines  used:  ? 

Variables  used:  p2,  Z  [  12 1 
Data  used:  Z(12| 

Error  code:  17 

number  0  -  illegal  VCO  number  passed 


number  1  -  illegal  source  number  passed 
The  “AMaux”  subroutine  block  is  used  to  select 
the  modulation  source  connected  to  the  passed  VCO 
through  the  AM  auxiliary  switch  matrix.  The  source 
numbers  and  sources  are: 

0  -  off 

1  -  external 

2  -  D/A  AM 

3  -  W175  (A) 


9.  ampset  (VCO  number,  dB  attenuation) 

Size:  408  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
dB  atten:  0-81 
Subroutines  used:  ? 

Variables  used:  p4,  Z  [  1 1 J 
Data  used:  Z  [  1 1  ] 

Error  code:  7 

number  0  -  illegal  VCO  number  passed 
number  1  -  passed  dB  value  out  of  range 

The  “ampset”  subroutine  block  is  used  to  set  the 
maximum  output  power  amplitude  level  of  the 
passed  VCO.  The  subroutine  sets  this  level  in  terms 
of  dB  below  the  absolute  maximum,  in  1  dB  steps. 
Should  a  programmer  wish  to  set  the  amplitude  level 
in  terms  of  dBm  of  output,  the  second  passed 
parameter  may  be  an  expression: 

X|7  +  2int((VCO#-  l)/6) 

-  (VCO#)  mod  2)  -  (dBm  value) 
or 

X(6  +  band  number)  -  (dBm  value) 
since  attenuation  (dB)  =  max.  output  power 
(dBm)  -  desired  output  power  (dBm). 

The  “ampset”  subroutine  block,  in  practice,  will 
usually  be  called  to  match  the  power  levels  of  dif¬ 
ferent  VCOs,  so  that  dB  attenuation  will  be  the  usual 
unit  of  the  second  passed  parameter. 


10.  AMown  (VCO  number,  rate,  number  steps) 
Size:  360  bytes 
Parameter  ranges: 

VCO  number:  M2  (integer) 

rate:  0.0305  -  I0VX[4]  [  =  25  1  (steps/s) 

number  steps:  2  1 

Subroutines  used:  ?,  AMval,  AMaux 
Variables  used:  p7,  U,  X 
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Data  used:  X[*  ],  Z[* ) 

Error  code:  8 

number  0  -  illegal  VCO  number  passed 
number  1  -  rate  out  of  range 
number  2  -  “AMval”  return  out  of  bounds 
(This  subroutine  ties  up  the  controller.) 

The  "AMown”  subroutine  block  is  used  to  run  a 
digital  am  signal  through  one  of  the  D/A  cards  in  the 
multiprogrammer  extender.  The  output  rate  and 
duration  are  determined  by  the  parameters  passed  to 
ihis  subroutine,  while  the  output  pattern  (dB  at¬ 
tenuation  at  any  step)  is  determined  by  the  return 
from  “AMval.”  The  “AMown”  subroutine  is  thus  a 
calling  shell  for  the  next  value  subroutine  “AMval.” 

The  controller  is  tied  up  when  running  this 
subroutine.  The  tie-up  time  is  determined  by  the 
quotient  of  the  passed  number  of  steps  divided  by  the 
passed  rate  (steps/s).  Should  a  programmer  wish  to 
specify  the  AM  pattern  by  time  duration  rather  than 
by  the  number  of  am  steps,  the  third  passed 
parameter  can  be  an  expression: 

(time  duration)  *  (rate)  . 

When  the  specified  number  of  AM  steps  has  been 
sent,  “AMcwn”  will  restore  the  card  word  held  in 
Z  [  *  1 .  This  will  be  identical  with  zero  unless  the  user 
assigns  some  other  value  to  the  appropriate  location 
in  Z[*  ]. 


11.  setVCO  (VCO  number) 

Size:  186  bytes 
Parameter  range: 

VCO  number:  1-12  (integer) 

Subroutine  used:  ? 

Variables  used:  p2,  Z  [  *  j 
Data  used:  Z  ( * ) 

Error  code:  10 

number  0  -  illegal  VCO  number  passed 
The  “set  VCO”  subroutine  block  is  used  to  select 
the  VCO  to  be  used  in  the  appropriate  rf  channel. 
The  VCO  numbers  are  given  in  Table  C-2.  Operator 
inputs  of  VCO  number  may  be  handled  through 
"inRFid”. 


12.  initial 

Size:  400  bytes 
No  parameters 
Subroutines  used:  ? 


Variables  used:  X,  Z  [  *  ] ;  no  flag  14 
Data  used:  none 
No  error  code 

The  “initial”  subroutine  block  is  used  to  clear  and 
initialize  the  hardware  status  of  ihe  simulator.  The 
subroutine  will  connect  VCO  B  in  each  rf  channel, 
turn  off  the  pulse  and  biphase  carriers,  set  maximum 
power  amplitude  level  attenuation,  turn  off  the  noise 
generators,  and  disconnect  the  fm  and  am  auxiliary 
switch  matrices.  The  subroutine  will  also  set  the 
format  of  the  multiprogrammer  cards  in  slots  2 
through  12  to  2’s  complement,  and  set  the 
timer/pacer  card  to  recirculating  mode.  The  Z  [  *  1 
array  will  also  be  initialized.  The  current  calibration 
data  identification  line  will  be  printed  for  reference. 


13.  stepmod  (VCO  number,  number  steps) 

Size:  464  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
number  steps:  >  1 
Subroutines  used:  ?,  stepval,  stepwt 
Variables  used:  p6,  U,  X,  Z I  *  ] 

Data  used:  Z  [  *  ] 

,  Error  code:  1 1 

number  0  -  illegal  VCO  number  passed 
number  1  -  “stepval”  return  out  of  bounds 
number  2  -  “stepwt”  return  out  of  bounds 
(This  subroutine  ties  up  the  controller.) 

The  “stepmod”  subroutine  block  is  used  to  run  a 
stepped  modulation  pattern  on  the  passed  VCO.  The 
step  centers  and  step  dwells  are  determined  by  the 
returns  from  “stepval”  and  “stepwt,”  respectively. 
The  “stepmod”  subroutine  is  thus  a  calling  shell  for 
the  nextvalue  subroutines  “stepval”  and  “stepwt." 

The  controller  is  tied  up  when  running  this 
subroutine.  The  tie-up  time  is  determined  by  the  sum 
over  the  passed  number  of  steps  of  the  “stwpwt” 
returns.  The  subroutine  will  restore  the  initial  tune 
center  when  it  completes. 


14.  ownswp  (VCO  number,  f,„„,  fhlllh,  rate, 
number  sweeps) 

Size:  740  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
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flow :  fm,„  to  fmax  (Hz)  (cf.  Table  C-2) 
fhigh;fmin  to  fmax  (Hz)  (cf.  Table  C-2) 
rate:  see  below  (Hz/s) 
number  sweeps:  >  1 
Subroutines  used:  ?,  fval  number 
Variables  used:  pl3,  W,  X  (indirect:  V) 

Data  used:  X [3  ] ,  Z[*  ]  (indirect:  Z$) 

Error  code:  9 

number  0  -  illegal  VCO  number  passed 
number  1  -  dwell  per  sweep  step  too  high 
number  2  -  dwell  per  sweep  step  too  low 
(This  subroutine  ties  up  the  controller.) 

The  “ownswp”  subroutine  block  is  used  to  run  a 
triangle  frequency  sweep  on  the  passed  VCO.  The 
sweep  parameters  are  determined  by  the  passed 
parameters.  The  controller  is  tied  up  when  running 
this  subroutine.  The  tie-up  time  is  determined  by: 

(time)  =  [2(fhigh  -  fk,u  )/(rate)  ]  *(number 
sweeps). 

The  subroutine  runs  a  triangle  that  is  linearly 
symmetrical  in  terms  of  the  tune  D/A  number  used. 
The  actual  frequency  sweep  will  be  asymmetrical 
since  a  real  tuning  curve  will  not  be  perfectly  linear. 
The  triangle  introduces  a  multiplier  of  two  into  the 
controller  tie-up  time,  as  given  above.  A  programmer 
may  easily  modify  this  subroutine  to  get  a  ramp 
sweep  (multiplier  of  one),  with  either  a  positive  or 
negative  slope. 

The  valid  parameter  range  for  the  passed  rate 
depends  on  the  passed  sweep  bandwidth  and  is 
related  to  restrictions  on  the  controller  dwell  at  each 
tune  D/A  number  step.  This  dwell  must  be  at  least 
the  controller  program  loop  execution  time  in  X  [  3  ] 
(corresponding  to  a  minimum  wait  of  zero)  and  at 
most  the  loop  time  plus  about  33  s  (corresponding  to 
a  maximum  wait  of  32767  ms).  There  will  be  a 
minimum  of  two  output  D/A  numbers  (going 
directly  from  one  sweep  limit  to  the  other)  and  a 
maximum  of  1  +  D,  where  D  is  the  difference  bet¬ 
ween  the  high  sweep  limit  D/A  number  and  the  low 
limit  D/A  number  (going  from  one  limit  to  the  other 
by  D/ A  steps  of  one). 

If  t  =  (dwell  at  D/A  number)  *  (number  of  D/A 
numbers),  then  the  valid  parameter  range  for  the 
passed  rate  is: 

<  rate  <  Af/t„„„  . 

This  can  be  worked  out  to  give  the  joint  restriction 
on  the  passed  rate  and  passed  sweep  limits  (including 
time-scale  factors): 

(2 x  10’)(X (3 1)  <  Af/rate  <(X(3j  + 
32767)0  +D)(103)  . 

The  “ownswp”  subroutine  will  restore  the  initial 
tune  center  when  it  returns. 


15.  swpl75  (VCO  number,  f„,  Af,  block  rate, 
function  number) 

Size:  898  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
f»:  fmin  tofmax  (cf.  Table  C-2) 

Af:f„  +  Af/2  <f„.ax; 
fo  -  Af/2>fm,„ 

block  rate:  0  -  19.5  kHz  (see  below) 
function  number:  0-1 1  or  14-21  (integer) 
Subroutines  used:  fset,  auxmod  (indirect:  ?, 
fval#) 

Variables  used:  pl4,  X.  U$  (indirect:  V,  W, 
Z[*|) 

Data  used:  X  ( * ) ,  W$  (indirect:  Z  [  *  | ,  ZS) 
Error  code:  14 

number  0  -  illegal  VCO  number  passed 
number  1  -  block  rate  out  of  bounds 
number  2  -  illegal  function  number 
number  3  -  (f„ ,  AD  combination  out  of 
bounds 

number  4  -  required  W 1 75  voltage  out  of 
range 

(This  subroutine  will  affect  the  display  formal  set¬ 
ting.) 

The  “swpl75”  subroutine  block  is  used  to  set  up 
the  FM  arbitrary  waveform  generator  (W175  (B))  to 
modulate  the  output  of  the  passed  VCO.  The  passed 
center  frequency  will  be  set  on  the  tune  card.  The 
passed  frequency  deviation  will  be  provided  by  the 
peak-to-peak  voltage  swing  of  the  W175. 

The  deviation  value  set  is  the  nominal  value  (at 
19.5  kHz  rate)  based  on  the  data  table  contents.  The 
actual  deviation  bandwidth  will  vary  somewhat  with 
the  W175’s  block  rate.  It  is  up  to  the  programmer 
and  operator  to  allow  for  this.  The  deviation  value 
also  depends  on  what  part  of  the  band  the  passed 
center  is  in;  this  is  handled  by  the  subroutine  in 
deciding  what  part  of  its  data  table  to  use. 

The  form  of  the  W175  modulation  depends  on  the 
contents  of  the  passed  waveform  function  block, 
whether  a  full  or  partial  block  is  used,  and  the  block 
rate  (or  rather,  sample  time  per  point).  The  passed 
rate  limits  in  this  subroutine  assume  a  full  block  is 
used;  a  programmer  or  operator  wishing  to  use  a 
partial  block  and  a  higher  rate  may  use  some  suitable 
scaling  expression  when  calling  the  subroutine. 

The  block  rate  can  be  related  to  the  modulation 
sweep  by: 

block  rate  =  (sweep  rate)/(k*Af)  . 

Here  k  is  some  scale  factor  included  to  allow  for 
block  size  and  contents.  For  example,  the  scale  factor 
for  a  full  size  block  using  function  number  0  is  2.  The 
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scale  factor  represents  the  number  of  maximum- 
minimum  value  swings  in  the  function  number 
contents. 

The  WI75  voltage  output  set  by  this  subroutine 
can  be  connected  to  other  VCOs  by  using  the  “aux- 
mod”  subroutine.  The  resulting  frequency  deviation 
on  the  other  VCOs  can  differ  from  that  set  on  the 
VCO  passed  to  “swpl75,”  depending  on  the  tune 
centers  and  tuning  curves  of  the  other  VCOs  (of 
course,  if  the  other  VCOs  are  in  different  bands,  the 
frequency  deviations  will  differ). 


16.  AM175  (VCO  number,  maximum  dB  at¬ 

tenuation,  block  rate,  function  number) 

Size:  396  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer) 
maximum  dB:  (see  below) 
block  rate:  0-19.5  kHz  (see  below) 
function  number:  0-11  or  14-21  (integer) 
Subroutines  used:  AMaux  (indirect:  ?) 
Variables  used:  p5,  U$  (indirect:  Z  [  1 2  ] ) 

Data  used:  X  ( *  ]  (indirect:  2  f  12 ) 

Error  code:  18 

number  0  -  illegal  VCO  number  passed 
number  1  -  block  rate  out  of  bounds 
number  2  -  illegal  function  number 
number  3  -  maximum  dB  value  out  of 
bounds 

(This  subroutine  will  affect  the  display  format  set¬ 
ting.) 

The  “AM175”  subroutine  block  is  used  to  set  up 
the  AM  arbitrary  waveform  generator  to  modulate 
the  output  of  the  passed  VCO.  The  form  of  the 
modulation  depends  on  the  contents  of  the  selected 
WI75  waveform  block  and  the  rale  at  which  that 
block  is  used. 

The  rate  passed  through  this  block  is  the  W175 
block  rate,  and  the  range  limits  assume  that  a  full 
block  is  used.  Partial  block  usage  at  rates  higher  than 
19.5  kHz  requires  that  an  appropriate  scaling  ex¬ 
pression  be  used  when  passing  the  rate. 

The  maximum  dB  attenuation  value  passed  sets  the 
maximum  signal  attenuation  due  to  the  am 
modulation  circuit  of  the  RF  channel  and  should  be 
understood  as  being  relative  to  the  power  level  at¬ 
tenuators  (“ampset”).  The  parameter  range  for  the 
passed  dB  value  is  related  to  the  valid  voltage  range 
of  the  WI75  and  to  the  dB/V  conversion  factor  of 
the  D/A  cards.  The  parameter  range  may  be  found 
as. 


0.001  X  [  1 1  ]  <  (dB  value)  < 

X  [  1 4 )  X  [  1 1 J  . 

The  usual  range  is  currently  (October  1981 )  estimated 
to  be  0.0055  to  27.5  dB. 


17.  DC175  (%  duty  cycle,  period,  WI75  number. 

VCO  numbers.  .  .) 

Size:  552  bytes 
Parameter  ranges: 

%  duty  cycle:  0-100  (°Io) 

Period:  >  0.051  (ms) 

W175  number:  1  (W175-A)  or  2  (W175-B) 
VCO  numbers:  up  losix  numbers;  must  lie 
in  different  rf  channels;  1-12  (integer) 
Subroutines  used:  pulse  (indirect:  ?) 

Variables  used:  pi 7,  X,  U$  (indirect:  Z(*  |) 
Data  used:  none  (indirect:  Z  [  *  ] ) 

Error  code:  15 

number  0  -  illegal  VCO  number  passed 
number  1  -  attempt  to  use  both  VCOs  in  an 
RF  head 

number  2  -  illegal  W 175  number  passed 
number  3  -  %  duty  cycle  out  of  range 
number  4  -  period  out  of  bound 
(This  subroutine  will  affect  the  display  format  set¬ 
ting.) 

The  “DC175”  subroutine  block  is  used  to  set  either 
of  the  arbitrary  waveform  generators  to  provide  a 
pulsed  squaie  wave  blinking  signal  to  the  pulse 
circuits  of  the  passed  VCOs.  Up  to  six  VCOs  may  be 
specified  in  the  call,  provided  they  lie  in  different  rf 
channels.  The  blinking  signal  is  defined  in  terms  of 
the  period  and  the  duty  cycle.  This  subroutine  will 
affect  the  W175  block  size;  it  will  also  turn  off  the  50 
n  output,  leaving  (he  0  0  output  to  be  sent  to  the 
pulse  circuits.  Once  set,  the  blinking  signal  may  be 
connected  to  or  disconnected  from  any  rf  channel  by 
using  “pulse.” 

The  period  (in  milliseconds)  may  be  replaced  at  the 
option  of  the  user  by  an  expression  using  rate  (in  Hz): 

period  (ms)  =  lOVrate(Hz)  . 

The  user  may  also  specify  pulse  width  rather  than 
period  by  using  the  expression: 

period  =  100*  pulse  width/%  duty  cycle. 


18.  T/P  (period,  VCO  number.  .  .) 
Size:  266  bytes 
Parameter  ranges: 
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period:  2  x  10  '  to  1  x  107  (ms) 

VCO  numbers:  up  to  six  numbers;  must  lie 
indifferent  rf channels;  1-12 (integer) 
Subroutines  used:  pulse  (indirect:  ?) 

Variables  used:  pl5,  X,  Z  [  13 1  (indirect:  Z  [  *  ]) 
Data  used:  none  (indirect:  Z  [  *  ] ) 

Error  code:  16 

number  0  -  period  out  of  bound 
number  1  -  illegal  VCO  number  passed 
number  2  -  attempt  to  use  both  VCOs  in  an 
rf  head 

The  “T/P”  subroutine  block  is  used  to  set  the 
timer/pacer  card  to  provide  a  50%  duty  cycle  square 
wave  blinking  signal  to  the  pulse  circuits  of  the 
passed  VCOs.  Up  to  six  VCO’s  (in  different  rf 
channels)  may  be  passed  in  the  same  call.  The 
subroutine  assumes  that  the  timer/pacer  card  is 
already  in  its  recirculating  mode.  At  the  option  of  the 
user,  rate  may  be  passed  instead  of  period,  using  the 
following  relation: 

period  (ms)  =  10' /rate  (Hz)  . 

The  period  will  be  held  in  Z  [  13  ] .  Pulse  width  is  one- 
half  the  period. 


19.  special  (band  number,  rate,  running  time, 
table  length) 

Size:  392  bytes 
Parameter  ranges: 

band  number:  0-3  (integer)  (cf.  Table  C-2) 
rate:  see  below  (Hz) 
time:  >  0  (s) 

Table  length:  >  0 
Subroutines  used:  ?,  valspec 
Variables  used:  p8,  U,  V,  W,  X,  Y,  Z;  no  flag 
14 

Data  used:  X  [  1  ] 

Error  code:  12 

number  0  -  illegal  band  number  passed 
number  1  -  illegal  table  length  passed 
number  2  -  rate  out  of  bounds 
(This  subroutine  ties  up  the  controller.) 

The  “special”  subroutine  block  is  used  to  simulta¬ 
neously  change  the  tune  centers  and  head  function 
control  words  of  all  the  available  VCOs  in  the  passed 
band.  The  new  values  are  determined  by  the  returns 
from  “valspec.”  The  dwell  at  each  set  of  tune  centers 
is  determined  by  the  passed  rate,  which  describes  the 
desired  number  of  tune  center  changes  per  second. 
The  parameter  range  for  the  rate  is  determined  by  the 
controller  wait  instruction  limits  and  by  the  program 


loop  execution  time.  The  range  may  be  expressed  as: 

107(32767  +  X [  1 J)  <rate<  lOVXH]  . 
In  practice,  the  valid  range  for  the  passed  rate  will  be 
O.OS-27.3  Hz. 

The  passed  table  length  parameter  is  in  turn  passed 
to  the  “valspec”  subroutine.  It  would  normally  be 
used  to  control  the  length  of  a  table  of  values  read  by 
“valspec.”  This  is  necessary  so  that  “valspec”  can 
determine  how  much  of  the  controller  memory  is 
given  over  to  data.  By  varying  the  passed  table 
length,  a  test  may  examine  the  effects  of  different 
repeat  periods  of  the  change  pattern,  with  the  longer 
periods  coming  closest  to  a  random  pattern.  It  should 
be  noted,  however,  that  the  table  length  parameter 
could  be  used  by  “valspec”  for  other  purposes,  or 
indeed  not  used  at  all;  the  actual  use  is  determined  by 
“valspec.”  The  controller  is  tied  up  when  running 
this  subroutine.  The  tie-up  time  (in  seconds)  is  passed 
directly  as  the  third  subroutine  parameter. 

The  subroutine  resets  the  noise  spots  by  sending 
out  new  channel  function  control  words.  In  cases 
where  the  user  wants  one  fixed  control  word  per 
VCO  (fixed  spots),  the  variables  Y,  Z,  and  V  can  be 
assigned  from  Z  [  * )  after  setting  the  spots  and  before 
this  subroutine  is  called;  then  “valspec”  need  only 
return  the  tune  data.  In  other  cases,  the  control  word 
may  vary.  For  example,  by  varying  the  noise  spot 
according  to  the  tune  frequency,  the  user  can  get  a 
pattern  in  which  the  apparent  noise  BW  does  not 
change  with  tune  center.  The  user  could  also  achieve 
a  pattern  in  which  a  set  of  apparently  fixed  BW  spots 
occasionally  changes  at  the  tune  change  step.  In 
addition,  biphase  modulation  may  be  switched  on  or 
off  at  each  step. 


20.  err  stp 

Size:  286  bytes 
No  parameters 
Subroutines  used:  non' 

Variables  used:  p24  (set  below);  no  flag  14 
Data  used:  Z 

Error  code:  not  applicable 
The  “err  stp”  subroutine  block  is  used  to  disable 
the  simulator  when  one  of  the  other  subroutines  has 
detected  a  fault.  This  subroutine  will  turn  off  the 
pulse  and  biphase  carriers  and  the  noise  of  each  of 
the  rf  channels.  In  doing  so,  it  will  reset  each  rf 
channel  to  VCO  B.  It  will  also  turn  off  the  50  $1 
outputs  of  the  arbitrary  waveform  generators. 


73 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

laurel  Maryland 


The  subroutine  will  print  out  the  error  code  in¬ 
formation  that  was  written  into  Z.  It  will  use  p2l-p24 
in  manipulating  Z;  these  p-numbers  were  selected  to 
avoid  overwriting  the  p-numbers  of  the  block  that 
entered  "err  stp.”  An  operator  could,  therefore, 
read  the  contents  of  p-numbers  as  an  aid  in  error 
(racing  beyond  the  printed  error  code. 

The  subroutine  ends  in  an  endless  loop,  Hashing  a 
notice  of  the  error.  There  is  no  explicit  recovery  from 
this  subroutine;  to  exit,  the  operator  must  stop  the 
machine,  read  the  p-numbers  if  desired,  and  then 
reset  the  controller. 


21.  shutoff 

Size:  236  bytes 
No  parameters 
Subroutines  used:  none 
Variables  used:  none  (no  flag  14) 

Data  used:  ront,  ern,  erl 
Error  code:  not  applicable 
The  “shutoff”  subroutine  block  is  used  to  disable 
the  simulator  when  the  controller  detects  an  execu¬ 
tion  error.  The  subroutine  will  turn  off  the  pulse  and 
biphase  carriers  and  the  noise  of  each  of  the  RF 
channels.  In  doing  so,  it  will  reset  each  rf  channel  to 
VCO  B.  It  will  also  turn  off  the  50  0  outputs  of  the 
arbitrary  waveform  generators. 

The  subroutine  will  print  out  the  error  information 
available  in  the  labels  rom,  ern,  and  erl.  The 
subroutine  then  ends  in  an  endless  message  loop  from 
which  there  is  no  explicit  recovery;  the  operator  must 
stop  and  then  reset  the  machine. 

The  subroutine  must  be  enabled  before  it  will  take 
effect.  If  not  enabled,  an  execution  error  will  stop  the 
program  without  affecting  the  output,  which  would 
be  frozen  at  the  state  at  which  the  error  occurred. 
The  enable  statement,  when  used,  should  be  among 
the  first  executable  program  lines.  The  subrouti  'e  is 
enabled  by  the  following  program  line: 
on  err  “shutoff’ 


22.  enter 

Size:  490  bytes 
No  parameters 
Subroutines  used:  none 
Variables  used:  p3;  no  flag  14 
Data  used:  US 


Error  code:  none 
Interior  label:  — 

The  “enter”  subroutine  function  block  is  used  to 
convert  an  input  entry  siring  (U$)  to  numeric  data 
form.  It  will  allow  data  to  be  entered  in  terms  of  a 
multiplier  unit,  such  as  GHz  or  MHz.  Syntax 
checking  is  not  rigorous  but  should  suffice. 

The  function  assumes  the  desired  input  is  con¬ 
tained  in  US  11,32).  It  will  sequentially  look  for  one 
of  the  multiplier  characters  it  recognizes.  The  first 
one  found  (regardless  of  its  position  in  the  string)  is 
taken  to  indicate  the  desired  unit.  The  rest  of  the 
string,  from  the  string  beginning  to  just  before  the 
character  position,  is  taken  to  contain  numeric  data. 
If  this  assumed  numeric  portion  of  the  string  con¬ 
tains  non-numeric  characters  (other  than  blanks),  the 
program  will  crash.  If  no  recognized  unit  character  is 
found,  the  entire  string  is  assumed  to  be  numeric. 

Since  the  function  only  looks  for  one  character,  an 
operator  only  needs  to  enter  that  character.  Thus, 
“G”  is  as  equally  acceptable  as  “GHz.” 

The  characters  currently  recognized  by  the  func¬ 
tion  are  listed  below,  in  the  order  in  which  the 
function  looks  for  those  characters.  The  function 
may  readily  be  extended  or  modified  to  better  match 
some  particular  program.  For  example,  a  program 
that  does  not  need  “milli-”  units  could  remove  the 
appropriate  “m”  line  and  modify  the  “M”  line  with 
the  “cap”  function.  Use  of  this  last  function  allows 
either  the  upper-  or  the  lower-case  character  to  in¬ 
dicate  the  units. 

The  characters  currently  recognized  and  their 
multipliers  are: 

gorG:  giga-(10v) 
k  or  K:  kilo-(IO') 
u  or  U:  micro-(10  6) 

M :  mega-(  1 O'1 ) 
m:  milli-(10  ') 
dor  D:  decibels  (I ) 
h  or  H:  hertz  (1) 
sor  S:  seconds  (1) 
e:  exponent  (1) 


23.  inRFid 

Size:  224  bytes 
No  parameters 
Subroutines  used:  none 
V ariables  used :  p  1 ;  no  flag  1 4 
Data  used:  U$ 

Error  code:  none 
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The  “inRFid”  subroutine  function  block  is  used  to 
accept  an  operator  input  specifying  a  VCO  and 
convert  it  to  the  form  used  by  the  other  subroutines. 
When  used,  this  function  will  prompt  an  operator  to 
specify  a  VCO  in  terms  of  the  rf  channel  number  and 
an  identifying  letter  (A  or  B),  which  is  the  informa¬ 
tion  an  operator  would  find  printed  on  the  simula¬ 
tor’s  front  panel.  Input  form  is  where  #  is  an 
integer  1-6  and  (is  a.  A,  b,  or  B.  Illegal  inputs  will  be 
rejected  and  the  operator  reprompted.  There  is  a 
default  value  of ‘‘6b,”  specifying  VCO  #  12. 


24.  load  Y$  (VCO  numbers.  .  .) 

load  X$  (VCO  numbers,  filter  numbers.  .  .) 
load  W$  (VCO  numbers.  .  .) 

Size:  540  bytes 
Parameter  ranges: 

VCO  number:  1-12  (integer):  up  to  six 
numbers;  must  lie  in  different 
rf  channels;  1-12  (integer) 
filter  number:  1-5 


Subroutines  used:  none 

Variables  used:  pl3(Y$,  W$);  p20(X$),  X, 

V$  [* );  no  flag  14 
Data  used:  Y$  [  *  ] ,  X$  [  *  J ,  W$  |  *  ] 

Error  code:  13 

number  0  -  illegal  VCO  number,  Y$ 
number  I  -  attempt  to  use  both  VCOs  in  rf 
head,  Y$ 

number  2  -  illegal  VCO  number,  X$ 
number  3  -  illegal  video  filter  number 
number  4  -  attempt  to  use  both  VCOs  in  rf 
channel,  X$ 

number  5  -  illegal  VCO  number,  W$ 
number  6  -  attempt  to  use  both  VCOs  in  rf 
channel  W$ 

(These  subroutines  will  set  the  tape  track  to  track  1 .) 
The  “loadYS,”  “loadX$”,and  “loadWS”  subrou¬ 
tine  blocks  are  used  to  load  data  strings  from  tape  to 
controller  memory.  The  standard  data  tape  format 
on  track  one  is  assumed.  Up  to  six  VCOs  may  be 
specified  in  a  single  call,  provided  all  six  lie  in  dif¬ 
ferent  RF  channels.  The  video  filter  number  passed  in 
“loadXS”  must  be  an  integer  1-5,  corresponding  to  a 
video  filter  value  of  1  kHz  to  5  MHz. 
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APPENDIX  P 

SUBROUTINE  BLOCK,  DETAILED  DESCRIPTION 


This  appendix  gives  a  detailed  description  of  the 
subroutine  block  program  instructions  as  of  October 
1981.  The  descriptions  include  what  each  program 
line  does  and  what  each  local  p-number  is  used  for. 
The  reader  should  refer  to  Appendix  O  for  a  short 
summary  description  of  each  subroutine  block  and  to 
Appendix  Q  for  a  program  listing. 

When  describing  the  lines  in  a  subroutine  block, 
this  appendix  will  use  relative  line  numbering  (e.g., 
first  line,  second  line,  etc.)  rather  than  absolute  line 
numbers  (e.g.,  line  0,  line  9,  etc.).  This  may  seem 
slightly  awkward;  however,  it  keeps  this  appendix 
free  of  the  actual  line  numbers,  so  that  the  descrip¬ 
tions  could  be  applied  to  any  listing  regardless  of  the 
location  of  the  subroutine  blocks  in  memory  and  re¬ 
gardless  of  whether  the  listing  for  a  subroutine  block 
was  from  some  subset  of  the  blocks.  Use  of  relative 
line  numbers  makes  the  description  of  each  block  in¬ 
dependent  of  other  descriptions.  Hence  one  block 
could  be  modified  by  adding  or  cutting  lines  without 
throwing  off  the  line  references  of  all  following  de¬ 
scriptions. 

For  convenience,  though,  the  subroutine  blocks 
are  described  in  the  same  order  in  which  they  would 
be  found  when  reading  the  listing  in  Appendix  Q. 
The  actual  line  number  in  the  listing  of  each  subrou¬ 
tine  block’s  first  line  is  given  as  an  aside  to  help  the 
reader  find  that  subroutine  in  Appendix  Q;  in 
keeping  with  the  point  of  the  previous  paragraph,  the 
reader  is  reminded  that  such  actual  line  numbers  may 
differ  for  other  listings. 

There  are  a  number  of  program  conventions  and 
other  common  features  that  would  be  tedious  to  de¬ 
scribe  repeatedly.  The  reader  should  find  it  easier  to 
follow  the  description  if  such  common  features  are 
described  separately;  then  they  only  need  to  be  men¬ 
tioned  in  the  actual  subroutine  block  description.  For 
example,  rather  than  describe  the  “err  sip”  branch 
in  each  subroutine,  the  branch  can  be  described  sep¬ 
arately  and  the  subroutine  block  description  need 
only  mention  when  the  branch  occurs.  Common 
features  are  described  below,  with  the  subroutine 
block  descriptions  following. 

The  subroutine  “?”  is  used  by  every  subroutine 
that  sends  data  to  the  multiprogrammer.  The  reader 
can  assume  this  to  be  present  between  a  subroutine’s 


output  to  the  multiprogrammer  and  the  subroutine’s 
return. 

The  subroutine  blocks  typically  use  the  sort  of 
structure  indicated  by  Figs.  P-1  and  P-2,  which  show 
general  flow  charts.  (Reference  2  includes  a  larger  set 
of  How  charts.)  The  general  set  type  flow  chart  shows 
that  a  typical  set  type  subroutine  block  will  check  the 
parameters  passed  to  it,  branching  to  “err  stp"  if  a 


Err  stp 


Err  stp 


Figure  P-1  —  Set  type  subroutine  block  (low  chart. 


:  J.  M.  Van  Parys,  MMG  ECM  Simulator  Software, 
Interim  Documentation,  JHU/APL  F4D-4-80(U)- 
002  (30  Sep  1980). 
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Subroutine  called 


Figure  P-2  —  Run  type  subroutine  block  flow  chart. 


bad  parameter  is  found.  It  would  perform  some  data 
manipulations  ranging  from  calculating  a  multipro¬ 
grammer  slot  number  to  searching  a  data  table  for 
entries  used  in  an  interpolation  and  may  involve 
calling  a  separate  subroutine.  The  results  may  be 
checked,  with  bad  results  causing  an  “err  sip" 
branch.  The  properly  formatted  and  addressed  out¬ 
put  would  then  be  sent  over  the  bus,  and  the  subrou¬ 
tine  would  return. 

The  general  run  type  flow  chart  shows  that  a  typi¬ 
cal  run  type  subroutine  is  similar  to  a  set  type,  up  to 
the  point  where  the  output  is  found  and  sent  over  the 
bus.  A  run  type  subroutine  will  set  up  a  for/next  loop 
to  handle  a  number  of  output  steps.  On  each  pass  of 
the  loop,  the  subroutine  would  find  the  next  output 
value,  typically  by  calling  a  nextval  subroutine  (see 
Appendix  O).  The  output  value  may  be  checked  with 
a  bad  value  leading  to  an  “err  stp"  branch.  The 
properly  formatted  and  addressed  output  would  be 
sent  over  the  bus  and  the  controller  would  then  wait 
for  some  amount  of  time  in  order  to  fix  the  output 
rate.  The  loop  pattern  would  repeat  until  the 
specified  number  of  output  steps  had  been  reached. 

There  are  several  exceptions  to  the  structure  sug¬ 
gested  by  the  general  flow  charts,  but  most  of  the  ex¬ 
ceptions  can  be  understood  with  the  general  flow 
charts  if  the  reader  mentally  masks  out  part  of  a  fig¬ 
ure  or  mentally  expands  one  step  to  include  addi¬ 
tional  details.  For  example,  the  reader  might 
mentally  mask  out  the  format  and  write  steps  in  Fig. 
P-1;  the  flow  chart  should  then  serve  to  describe  the 
structure  of  a  calculation  subroutine  such  as 
“fval#.”  The  “?”  subroutine  block  is  one  that 
cannot  be  modeled  with  the  general  flow  charts;  it  is 
basically  just  a  loop  that  waits  for  a  bit  in  the  multi¬ 
programmer’s  busy  instruction  register  to  be  unset 
before  it  returns. 

The  “err  stp”  branching  noted  in  the  general 
flow  charts  is  a  conditional  branch  to  that  label.  The 
branch  is  activated  if  some  conditional  test  indicates 
that  a  value  is  illegal  or  out  of  range.  As  part  of  the 
branch,  the  subroutine  blocks  will  assign  a  coded 
number  to  the  variable  Z;  this  number  will  indicate 
the  cause  of  the  “err  stp”  branch  that  shut  down 
the  controller  (see  Appendix  F  and  Table  F-l).  The 
form  of  an  "err  stp”  branch  is  typically: 

if  (value)  ( <,  >)  (limit);  fcode)  — Z; 
gto  “err  stp." 

In  the  subroutine  block  descriptions,  such  a  condi¬ 
tional  test  and  branch  to  “err  stp”  will  usually  be 
indicated  by  noting  a  possible  error  branch. 
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The  subroutine  blocks  will  typically  use  a  consis¬ 
tent  pattern  in  passing  parameters,  such  as  giving  a 
VCO  number  first,  then  a  tune  frequency,  etc.  (see 
Appendix  C).  Typically  (there  are  exceptions,  such  as 
"DC175”,  and  “T/P”),  the  first  passed 
parameter  is  a  VCO  number,  so  in  reading  the  listings 
the  reader  can  generally  take  pi  to  be  a  VCO  num¬ 
ber. 

Certain  common  calculations  are  used  to  find  such 
things  as  multiprogrammer  tune  and  function  control 
slot  numbers  and  the  half  of  a  tune  card  that  should 
be  used.  These  are  indicated  in  Table  C-2. 

Tune  D/A  numbers  and  W175  voltages  are  found 
by  simple  linear  interpolation  from  data  in  the  appro¬ 
priate  tables.  The  particular  table  entries  used  are 
found  by  sequentially  checking  all  appropriate  table 
entries  for  the  VCO  involved  until  some  condition 
(typically  the  desired  value  being  greater  or  less  than 
the  tabled  value)  is  met.  This  can  be  done  since  the 
tabled  data  are  ordered  (i.e.,  increasing  attenuator 
setting,  increasing  W175  voltage,  or  increasing 
frequency).  Because  no  table  search  involves 
checking  more  than  eight  entries,  this  simple  easy-to- 
program  approach  is  used;  one  of  the  theoretically 
more  efficient  table  lookup  algorithms  would  not 
give  any  noticeable  improvement  for  such  a  short 
table  search.  On  the  noise,  fill,  and  W175  tables,  the 
search  is  narrowed  down  by  specifying  a  band  part 
number  (see  Appendix  E). 

The  detailed  descriptions  of  the  subroutine  blocks 
will  use  a  common  form  to  make  it  easier  to  pick  out 
desired  information.  This  form  is: 

“Label  name”  (passed  parameters) 

(Size  in  bytes;  listing  line  number  of  first  line) 

Brief  statement  of  what  the  subroutine  does 
Line  descriptions 
first  line 
second  line 


The  first  line  is  numbered  1,  the  second  line  is 
numbered  2,  and  so  on.  The  reader  is  again  reminded 
that  these  numbers  are  taken  with  reference  to  the 
subroutine  and  not  to  the  actual  line  numbers  of  the 
subroutine  block  programming,  and  that  the  listing 
line  number  of  the  first  line  of  the  subroutine  is  for 
the  particular  listing  in  Appendix  Q. 

“?”  (bit  number,  word  number) 

(56  bytes;  line  0) 


Checks  multiprogrammer  busy  instruction  register 
until  instruction  bit  checked  is  unset. 

1.  Reads  busy  instruction  register  status  words 
into  p3  and  p4.  If  passed  bit  of  passed  word  is 
set,  the  program  jumps  to  the  beginning  of  the 
line. 

2.  Returns;  reached  when  bit  is  not  set  (unset). 


“fval#”  (VCO  number,  f„) 

(406  bytes;  line  2) 

Finds  a  D/A  number  corresponding  to  the  passed 

frequency  by  linear  interpolation  front  the  tune  data. 

1 .  Scales  passed  frequency  to  gigahertz  and 
checks  that  it  is  not  less  than  the  minimum 
tabled  frequency  in  Z$  (note  that  the  VCO 
number  is  not  checked;  this  will  normally  be 
done  by  another  subroutine  calling  this  one). 

2.  Sets  up  a  fo1  next  loop  (index  V)  to  find  the 
first  table  entry  less  than  or  equal  to  the  scaled 
frequency.  If  such  an  entry  is  found,  the  entry 
number  is  saved  in  p4  and  the  loop  ended  by 
manipulating  the  index  within  the  loop. 

3.  Checks  that  a  table  entry  was  found  in  the 
second  line;  otherwise  the  passed  frequency 
was  too  high  and  an  error  branch  is  set . 

4.  Sets  low  and  high  data  table  entry  points  in  p4 
and  p9,  respectively.  Gets  the  high  D/A  num¬ 
ber  and  the  difference  between  high  and  low 
D/A  numbers  and  saves  them  in  p6  and  p5, 
respectively. 

Note:  Low  and  high  refer  to  the  entry  numbers;  low 
frequency  will  be  less  than  high  frequency  but 
“low”  D/A  number  may  or  may  not  be  less 
than  “high”  D/A  number. 

Note:  If  the  linear  interpolation  is  thought  of  in 
terms  of  X  and  Y,  the  D/A  number  corre¬ 
sponds  to  the  Y  axis. 

5.  Gets  the  high  frequency  (p7)  and  the  high-low 
frequency  difference;  then  calculates  the  local 
slope  of  the  Z$  data  about  the  entry  points. 
The  slope  is  saved  in  p5. 

6.  Calculates  the  desired  D/A  number  corres¬ 
ponding  to  the  passed  frequency  and  assigns  it 
to  W.  Checks  that  the  D/'A  number  is  within 
the  8  bit  absolute  D/A  range. 

7.  Returns. 

“fset”  (VCO  number,  f,, ) 

(268  bytes;  line  9) 

Sets  the  passed  frequency  as  the  tune  center  for  the 

specified  VCO.  This  calls  “fval#”. 
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1 .  Sets  flag  14,  then  checks  that  the  VCO  number 
is  legal. 

2.  Calculates  the  RF  number  (p3)  and  finds  the 
binary  shift  and  mask  bytes  (p4  and  p5, 
respectively). 

3.  Calls  “fval#”  to  get  the  D/A  number,  then 
manipulates  the  D/A  number  to  fit  into  the 
proper  half  of  Z  ( *  J . 

4.  Sends  the  new  Z[*)  word  to  the  multipro¬ 
grammer,  clears  flag  14,  and  returns. 

“fnoise”  (VCO  number,  spot  rf  BW,  video,  band 
part) 

(1316  bytes;  line  13) 

Sets  a  noise  spot  on  the  output  from  the  specified 
VCO,  using  the  in-channel  noise  generator  and  fill 
oscillator.  Band  part  may  be  a  number  I  (low  part  of 
band),  2  (mid),  or  3  (high);  it  may  be  a  frequency,  or 
it  may  be  defaulted  (not  given)  to  midband.  The  spot 
can  be  turned  off  by  calling  the  subroutine  with  just 
the  VCO  number  given  or  by  passing  a  value  of  zero 
for  the  spot  rf  bandwidth.  This  subroutine  may  call 
"fset”. 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Calculates  the  rf  number  (p5)  and  the  channel 
function  control  slot  number  (plO).  The 
minimum  frequency  is  calculated  from  the 
band  number  and  saved  in  pi  1 . 

3.  Checks  if  the  spot  rf  BW  is  zero  (explicitly 
passed  zero  or  only  the  VCO  number  passed); 
if  it  is,  the  fill  attenuation  (p  1 3)  and  noise 
attenuation  (pl4)  values  are  set  and  the 
subroutine  branches  to  its  “fnout”  label. 

4.  Checks  if  the  video  was  specified  by  a  video 
filter  number  0-6;  if  so,  that  number  is 
assigned  to  p6  and  the  subroutine  jumps  three 
lines  to  the  seventh  line. 

5.  Checks  if  the  video  was  specified  as  5  MHz;  if 
so,  sets  the  video  number  (p6)  and  jumps  two 
lines  to  the  seventh  line. 

6.  Calculates  the  video  number  (p6)  from  the 
video  bandwidth  and  checks  that  it  (and  hence 
the  passed  video  bandwidth)  is  legal. 

7.  Uses  the  passed  band  part  parameter  as  an 
initial  value  for  the  reference  center  frequency 
(pi 3).  Checks  if  the  band  part  was  actually 
passed;  if  not,  it  will  set  a  midband  frequency 
as  the  reference  center  (pi 3)  and  will  set  the 
data  table  band  part  offset  (p7),  then  jump 
four  lines  to  the  eleventh  line. 

8.  Checks  if  the  band  part  was  specified  by  a 
low/mid/high  code  number;  if  so,  it  sets 


reference  center  (pi 3)  and  table  offset  (p7) 
values,  then  jumps  three  lines  to  the  eleventh 
line. 

9.  If  this  line  is  reached,  it  is  assumed  the  band 
part  was  specified  by  passing  a  frequency.  This 
line  checks  that  the  value  is  within  the  band 
limits,  the  high  limit  being  assumed  equal  to 
twice  the  low  limit. 

10.  Calls  “fset"  to  set  the  passed  band  part 
frequency  as  the  tune  center,  then  finds  the 
data  table  band  part  offset  (p7). 

1 1.  Checks  that  the  desired  spot  bandwidth  about 
the  reference  center  will  not  be  clipped,  by 
checking  if  the  spot  would  overlap  the  band 
limits. 

12.  Divides  the  desired  spot  RF  BW  into  fractions 
from  the  fill  oscillator  (p8)  and  the  noise 
generator  (p9)  and  initializes  full  attenuation 
for  the  fill  attenuator  (pi 3)  and  noise  at¬ 
tenuator  (pi 4)  settings.  If  the  video  was 
specified  as  zero,  it  will  reset  the  fill  and  noise 
spots  so  that  all  of  the  desired  spot  rf  BW  will 
come  from  the  fill  oscillator. 

13.  Checks  that  the  fill  oscillator  spot  is  not 
greater  than  the  zero  attenuation  fill  oscillator 
bandwidth.  If  the  spot  is  greater,  then  the  fill 
spot  is  reset  to  the  zero  attenuation  value,  the 
fill  attenuation  value  set  for  zero  attenuation, 
the  noise  generator  spot  adjusted  to  maintain 
the  overall  spot  bandwidth,  and  a  flag  (pi  5)  set 
to  indicate  that  this  resetting  has  been  done. 

Note:  This  check  may  be  unnecessary  or  undesirable 
in  practice.  If  the  user  prefers,  the  conditional 
action  after  the  check  could  be  changed  from 
the  resetting  to  an  "err  stp”  branch;  line  14 
should  be  modified  to  match,  and  lines  15,  16, 
and  19  could  be  cut. 

14.  Similar  to  the  thirteenth  line,  but  for  the  noise 
generator  spot.  The  flag  is  p  1 6.  See  the  note 
above. 

15.  Checks  if  both  resetting  flags  (thirteenth  and 
fourteenth  lines)  have  been  set. 

16.  Checks  if  the  fill  spot  has  been  reset;  if  so,  the 
program  jumps  three  lines  to  the  nineteenth 
line. 

17.  Sets  up  a  for/next  loop  (index  X)  to  search  the 
fill  oscillator  data  for  the  first  tabled  entry  less 
than  the  desired  fill  spot.  If  such  an  entry  is 
found,  the  previous  index  is  used  for  the  at¬ 
tenuator  setting  (i.e. ,  if  the  table  entry  for  an 
attenuator  setting  of  4  is  found  to  be  less  than 
the  desired  spot,  then  the  previous  attenuator 
setting,  in  this  case  a  setting  of  3.  is  used  as 
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being  the  closest  setting  greater  than  or  equal 
to  the  desired  spot).  If  no  table  entry  is  found, 
then  the  full  attenuator  setting  that  was  set  in 
the  twelfth  line  is  used. 

Note:  The  table  search  may  be  easily  modified  if 
actual  use  of  the  simulator  suggests  a  better 
approach.  The  check  could  be  for  “less  than 
or  equal  to”  and  the  present  index  used  for  the 
attenuator  setting  (replace  X-l  by  X).  The 
check  could  also  be  modified  to  branch  to  "err 
stp”  if  the  full  attenuation  value  is  too  large 
(see  second  and  third  lines  of  “fvaW”). 

18.  Completes  the  fill  oscillator  data  search. 

19.  Checks  if  the  noise  generator  spot  has  been 
reset;  if  so,  the  program  jumps  three  lines  to 
the  twenty-second  line. 

20.  Similar  to  line  17,  but  for  the  noise  generator 
attenuation.  The  note  after  line  17  also  applies 
to  this  line. 

2 1 .  Completes  the  noise  generator  data  search. 

22.  “fnout”  label.  Sets  flag  14  and  masks  out  the 
proper  Z  [  *  )  card  word. 

23.  Forms  the  Z  [  *  ]  channel  function  control 
word  so  it  contains  the  new  fill  oscillator  and 
noise  generator  attenuator  settings  and  the 
new  video  number. 

24.  Sends  the  new  Z[*]  word  to  the  multipro¬ 
grammer,  clears  flag  14,  and  returns. 


“pulse”  (VCO  number,  source  number) 

(232  bytes;  line  37) 

Sets  the  pulse  circuit  of  the  RF  channel  of  the 
specified  VCO  so  as  to  connect  the  specified  source 
(see  Table  C- 1). 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Checks  that  the  source  number  is  legal. 

3.  Sets  flag  14  and  forms  the  new  Z(*|  head 
function  control  card  word. 

4.  Sends  the  new  Z[*|  word  to  the  multipro- 
grammer,  clears  flag  14,  and  returns. 


“biph”  (VCO  number,  source  number) 

(230  bytes;  line  41 ) 

Sets  the  biphase  circuit  of  the  RF  channel  of  the 
specified  VCO  to  provide  the  specified  biphase 
modulation  (see  Table  C-l).  This  subroutine  is 
similar  to  “pulse”  (immediately  above),  differing 
only  in  the  values  of  the  shift  and  mask  bytes.  The 
line-by-line  description  of  “pulse”  can  be  directly 
used  for  this  subroutine  as  well. 


“auxmod”  (VCO  number,  source  number) 

(300  bytes;  line  45) 

Sets  the  auxiliary  fm  switch  matrix  to  connect  the 
specified  source  to  the  ri  channel  of  the  specified 
VCO. 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Checks  that  the  source  number  is  legal. 

3.  Sets  flag  14,  then  forms  the  new  Z|12J 
auxiliary  switch  word  to  represent  the  new 
status  of  the  matrix,  including  the  RF  channel 
involved. 

4.  Sends  the  new  Z[12|  word  to  the 
multiprogrammer  and  wails  a  minimal  lime 
for  that  value  to  settle. 

5.  Disables  the  switch  matrix  from  following 
changes  until  this  subroutine  is  called  again, 
clears  flag  14,  and  returns. 

“AMaux”  (VCO  number,  source  number) 

(292  bytes;  line  50) 

Sets  the  am  auxiliary  switch  matrix  to  connect  the 
specified  source  to  the  rf  channel  of  the  specified 
VCO.  This  subroutine  is  virtually  identical  to 
“auxmod”  (immediately  above),  differing  only  in 
the  shift  and  mask  bytes,  and  the  same  line-by-line 
description  used  for  “auxmod”  also  describes 
“AMaux.” 


“ampsel”  (VCO  number,  dB  attenuation) 

(408  bytes;  line  55) 

Sets  the  output  power  reference  level  by  specifying 

the  dB  of  attenuation  (0-81  in  1  dB  steps)  set  by  the 

level  set  attenuators. 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Assigns  the  passed  dB  value  into  a  local 
variable  (p4)  so  that  a  later  instruction  (the 
seventh  line)  need  not  depend  on  some  con¬ 
ditional  assignments  (third  and  fourth  lines). 
This  line  also  checks  that  the  passed  dB  value 
is  legal. 

3.  Checks  if  the  passed  dB  value  is  81  dB;  if  so,  it 
sets  the  coarse  (p4)  and  fine  (p3)  attenuator 
codes,  then  jumps  three  lines  to  the  sixth  line. 

4.  Similar  to  the  third  line,  except  that  it  checks 
for  a  passed  value  of  80  dB. 

5.  Sets  the  fine  attenuation  code  (p3);  p5  is  used 
as  a  temporary  holding  variable. 

6.  Sets  flag  14  and  masks  out  the  previous  power 
level  data  from  Z(  11 J. 

7.  Forms  the  new  Z  [  1 1 J  word  to  contain  the  RF 
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channel  number  (offset  by  -  1  to  match  the 
hardware),  the  fine  attenuation  code,  and  the 
coarse  attenuation  code. 

8.  Sends  the  new  Z [  1 1  |  word  to  the  multipro¬ 
grammer,  clears  flag  14,  and  returns. 


"AMown’  (VCO  number,  rate,  number  of  output 
■  teps) 

(360  bytes;  line  63) 

Uses  the  controller  to  run  an  am  pattern  through 
one  of  the  am  D/A  cards  in  the  multiprogrammer 
extender.  The  pattern  is  determined  by  the  user- 
provided  nextval  subroutine  “AMval”  (see  Ap¬ 
pendix  D).  This  also  calls  “AMaux”. 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Calculates  the  wait  time  (p4)  and  checks  that  it 
is  within  range. 

3.  Calculates  the  multiprogrammer  extender  slot 
number  of  the  am  D/A  card  for  the  rf 
channel  of  the  specified  VCO  (p5),  then  calls 
“AMaux”  to  connect  the  Rt  channel  and  D/A 
card.  The  line  then  sets  up  a  for/next  loop 
(index  X)  to  run  the  output  pattern,  starting  by 
calling  the  nextval  “AMval”. 

4.  Checks  that  the  “AMval”  return  in  U  of  a  dB 
value  is  within  range. 

5.  Sends  the  value  in  U  to  the  multiprogrammer, 
waits  to  establish  the  rate,  and  continues  the 
for/next  loop. 

6.  Restores  the  D/A  card  to  the  value  held  in 
Z  [  *  |  before  the  output  pattern  was  run  (unless 
the  user  directly  assigns  a  new  value  to  Z[*  ] 
after  “initial”,  this  will  amount  to  setting  the 
D/A  card  to  0  dB  attenuation  when  the  outprt 
loop  is  done).  The  line  then  returns  the 
subroutine  to  the  calling  program. 


“set VCO”  (VCO) 

(1 86  bytes;  line  69) 

Sets  the  active  VCO  of  the  pair  in  each  rf  channel. 

1 .  Sets  flag  14,  then  checks  that  the  VCO  number 
is  legal. 

2.  Calculates  the  channel  function  control  card 
slot  number  (p2)  and  forms  the  new  Z[*| 
word.  An  even  VCO  number  (“B”  labeled 
VCO  of  an  rf  channel  pair;  gives  a  control  bit 
of  0. 

3.  Sends  the  new  Z(*|  word  to  the  multipro- 
grammer,  clears  flag  14,  and  returns. 


“initial” 

(400  bytes;  line  72) 

Sets  the  initial  status  of  the  simulator  (sec  Ap¬ 
pendixes  B  and  J,  and  Table  J-l).  This  will  set  the 
tape  to  track  1.  Z  [  *  J  and  U$  must  be  dimensioned 
before  calling  this. 

1 .  Clears  the  bus,  gets  and  prints  the  calibration 
data  identification  line  (see  Appendix  E),  waits 
to  allow  the  multiprogrammer  to  pass  self-test, 
and  sets  the  limer/pacer  card  to  its  recir¬ 
culating  mode. 

2.  Waits  to  allow  the  “WF”  instruction  of  the 
last  line  to  complete  (“?”  cannot  be  used  since 
“WF”  is  not  monitored  by  the  busy  in¬ 
struction  register),  then  initializes  Z  [  *  j .  A 
for/next  loop  (index  X)  is  set  up  to  change  the 
data  format  of  the  digital  output  cards  in  slots 
2-12  to  2’s  complement.  A  brief  wait  allows 
each  instruction  to  complete  before  the  next  is 
sent  (it  was  found  in  practice  that  “?”  would 
not  work  if  used  when  setting  the  data  for¬ 
mats). 

3.  Completes  the  loop  begun  in  line  2.  A  new 
for/next  loop  is  begun  to  initialize  the  status  of 
the  RF  channels.  It  first  sets  the  channel 
function  control  cards  and  the  corresponding 
Z  [  *  1  words. 

4.  As  part  of  the  loop  begun  in  line  3,  the  VCO 
select  bit  is  flip-flopped  to  ensure  that  it  will  be 
in  a  known  stale. 

Note:  The  fourth  line  of  “initial”  is  an  example 
wimin  the  subroutine  blocks  (however  trivial) 
of  use  of  the  multiprogrammer’s  capability  for 
accepting  several  instructions  at  the  same  time. 

5.  Continuing  the  loop  begun  in  the  third  line, 
this  line  sets  the  auxiliary  fm  and  am  switch 
matrices  to  off  states. 

6.  Sets  the  level  set  attenuators  to  provide  full 
output  power  attenuation,  then  continues  the 
loop  begun  in  the  third  line. 

7.  Disables  the  auxiliary  switch  matrices  from 
following  changes,  then  returns. 


“slepmod”  (VCO  number,  number  of  output  steps) 
(464  bytes;  line  79) 

Uses  the  controller  to  run  an  arbitrary  output 
pattern  involving  the  specified  VCO.  The  pattern  is 
determined  by  user-provided  nextval  subroutines 
“stepval”  and  “siepwt”  (see  Appendix  D). 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Calculates  the  tune  card  slot  number  (p4). 
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3.  Sets  up  p6  for  local  use  in  place  of  the  tune 
word  in  Z[*];  then  finds  the  shift  (p5)  and 
mask  (p3)  bytes. 

4.  Sets  flag  14,  sets  up  a  for/next  loop  (index  X) 
to  run  the  output  pattern,  and  calls  the  nextval 
“stepval”. 

5.  Checks  that  the  “stepval”  return  in  U  of  a 
D/A  number  is  within  the  absolute  8  bit  range 
for  that  number. 

Note:  The  D/A  number  range  that  gives  meaningful 
frequency  outputs  will  generally  be  con¬ 
siderably  less  than  0-255;  however,  the  ab¬ 
solute  range  is  easier,  quicker,  and  shorier  to 
check  than  the  proper  limits  held  in  the  ap¬ 
propriate  parts  of  Z$. 

6.  Forms  and  sends  to  the  multiprogrammer  the 
new  tune  word. 

7.  Calls  the  nextval  “stepwt”  to  get  the  lotal 
dwell  until  the  next  output  change,  offsets  the 
return  in  U  of  a  dwell  in  milliseconds  by  the 
loop  time  to  get  the  wait,  and  checks  that  the 
wait  is  within  range. 

8.  Waits  to  establish  the  dwell,  then  continues  the 
output  loop. 

9.  Restores  the  original  pre-“stepmod”  tune 
data,  clears  flag  14,  and  returns. 


“ownswp"  (VCO  number,  low  frequency,  high 
frequency,  rate,  number  of  sweeps) 

Uses  the  controller  to  run  a  frequency  sweep  by 
changing  the  tune  center  of  the  specified  VCO.  A 
triangle  waveform  is  used  to  change  the  tune  card 
D/A  number  -,  ■.  -  frequency  may  be  nonlinear  and 
nonsymmetri'  'o  nonlinearities  and  hysteresis 

effects  in  tuning  curve.  This  calls  “fval#”. 

I  Checks  that  the  VCO  number  is  legal. 

2.  Calculates  that  tune  card  slot  address  (p  10), 
and  the  shift  (p!4)  and  mask  (p  1 2)  bytes. 

3.  Masks  out  ihe  tune  word  in  Z[*  ]  and  assigns  it 
to  p!5  for  local  use.  The  line  then  calls 
“fval#”  to  get  the  low  frequency  D/A 
number,  saving  ii  in  p7. 

4.  Calls  “fval#”  to  get  the  high  frequency  D/A 
number,  saving  it  in  p8;  then,  if  necessary,  will 
swap  p7  and  p8  (using  pi  1  as  a  holding 
variable)  so  that  the  low  D/A  number  in  p7  is 
really  less  than  the  high  D/A  number  in  p8. 

5.  Calculates  the  time  allowed  for  one  sweep  (in 
milliseconds)  from  the  frequency  limits  and 
the  rate,  saving  this  time  in  pi  I.  The  line  also 


gets  the  difference  between  the  high  and  low 
D/A  numbers,  saving  this  in  p6.  The  quotient 
of  the  time  for  one  sweep  divided  by  the  D/A 
number  difference  is  offset  by  the  loop  time 
and  saved  in  p  1 3 .  This  gives  the  wait  time  that 
would  be  needed  if  the  controller  swept  be¬ 
tween  frequency  limits  with  a  D/A  number 
change  per  step  of  one.  Such  a  sweep  would 
give  the  best  resolution  and  also  would  be  used 
to  get  the  slowest  possible  sweep.  The  w'ait 
time  is  checked  to  see  if  it  is  too  large  (i.e.,  if 
the  rate  is  too  low  for  the  specified  frequency 
sweep  range,  or  alternately,  if  the  frequency 
sweep  range  is  too  large  for  the  specified  rate). 

Note:  The  line  should  also  check  that  the  value  in  pi  3 
is  not  less  than  zero,  which  would  indirectly 
check  either  the  order  of  the  low  and  high 
frequency  limits  or  the  sign  of  the  rate  (but  not 
both  simultaneously;  if  the  low  and  high  limits 
are  reversed  and  the  rate  is  negative,  pi 3 
would  be  positive).  The  line  would  have  to  be 
split  in  two  for  the  zero  check  to  be  made, 
however. 

Note:  If  the  user  does  need  a  controller  run  sweep  in 
which  each  step  needs  more  than  32767  ms.  the 
user  can  modify  the  wait  method  to  get  any 
wail  greater  than  zero  (e.g.,  a  for/next  loop 
repeating  a  number  of  waits,  or  use  of  the 
multiprogrammer  clock). 

6.  Sets  the  D/A  number  change  per  output  step 
(p9)  as  1 .  If  the  wait  lime  in  pi  3  is  greater  than 
or  equal  to  zero,  this  is  the  combination  of 
D/A  number  change  pei  step  and  wail  per  step 
that  will  be  used,  and  the  program  jumps  to 
the  eighth  line. 

7.  If  this  line  is  reached,  then  a  D/A  number 
change  per  output  step  of  one  would  take  too 
long.  The  wail  per  step  is  reset  as  zero,  and  the 
line  calculates  the  D/A  number  change  that 
would  then  be  needed.  This  change  would 
typically  be  greater  than  one,  giving  less 
resolution  but  taking  less  time  to  run.  The  line 
checks  that  the  D/A  number  change  is 
achievable  (an  error  here  would  imply  that  the 
rate  is  too  high  for  the  specified  frequency 
limits,  or  alternately,  that  the  frequency  limits 
are  too  low  for  the  specified  rate). 

8.  Sets  up  a  for/next  loop  (index  Y)  to  run  the 
specified  number  of  sweeps,  then  sets  up  an 
inner  for/next  loop  (index  X)  to  run  the  up 
slope  of  the  D/A  number  triangle  waveform. 

Note:  The  user  can  easily  modify  this  subroutine  to 
use  a  ramp  waveform  to  run  the  D/A  number 
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sweep  by  cutting  out  one  or  the  other  of  the 
inner  (X  index)  loops.  The  user  is  reminded 
that  up  and  down  refer  to  the  sweep  of  the 
D/A  numbers  and  this  may  or  may  not 
correspond  to  the  sense  of  the  resulting 
frequency  sweep. 

9.  Handles  the  word  formatting, 
multiprogranimer  output,  and  wait  time  for 
each  step  of  the  up  slope. 

10.  Sets  up  an  inner  for/next  loop  to  handle  the 
formatting  and  multiprogrammer  output  for 
each  step  of  the  down  slope. 

1 1.  Waits  to  establish  the  rate  of  the  down  slope, 
then  continues  with  the  output  sweep  loop. 
When  the  output  sweep  loop  is  done,  the 
original  presweep  tune  data  are  restored. 

12.  Clears  flag  14  and  returns. 

“swpl75”  (VCO  number,  center  frequency, 
frequency  deviation,  W175  block  rate,  function 
number) 

(898  bytes;  line  100) 

Sets  up  the  fm  W175  and  tune  center  to  give  an  FM 

waveform  as  specified  by  the  passed  parameters.  This 

calls  “fset”  and  “auxmod”. 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Calculates  the  RF  number  (p6),  then  checks 
that  the  block  rate  is  legal  (see  Appendix  H). 

3.  Checks  that  the  function  number  is  legal. 

4.  Calculates  the  band  number  (p7)  and  initializes 
the  data  table  pointer  (pi 2). 

5.  Calculates  a  minimum  frequency  based  on  the 
band  of  the  specified  VCO  (plO)  and  finds  the 
data  table  part  offset  (pH). 

6.  Checks  that  the  frequency  deviation  about  the 
center  will  be  within  range. 

7.  Sets  up  a  for/next  loop  (index  X)  to  search  the 
WS  data  able  for  the  first  entry  greater  than 
or  equal  to  the  desired  deviation  bandwidth.  If 
such  an  entry  is  found,  then  the  table  number 
of  the  entry  is  saved  in  p  1 2  and  the  search 
ended  by  manipulating  the  for/next  index 
within  the  loop.  The  value  of  the  data  table 
entry  will  be  in  pl4;  this  is  the  high  voltage. 

Note:  If  the  voltage-bandwidth  calibration  curve  is 
thought  of  in  terms  of  X  and  Y,  voltage  is  the 
Y  axis. 

8.  Completes  the  table  search.  If  no  entry  was 
found  in  the  search,  the  subroutine  will  use  the 
last  entry  (highest  tabled  voltage). 

9.  Finds  a  low  voltage  (pi 3)  to  be  used  with  (he 
high  voltage  in  pi 4. 


10.  Calculates  the  voltage  (p8)  corresponding  to 
(he  specified  frequency  deviation  bandwidth. 
The  local  slope  of  the  calibration  curve  is  in 
pl3. 

11.  Checks  that  the  voltage  calculated  in  the 
previous  line  is  legal. 

12.  Sets  up  U$  to  contain  the  specified  block  rate. 

13.  Modifies  US  to  also  specify  the  voltage  am¬ 
plitude  and  offset  and  the  function  number, 
and  also  to  turn  on  the  50  ohm  output. 

14.  Calls  “fset”  to  get  the  specified  tune  frequen¬ 
cy,  sends  US  to  the  fm  W175  to  get  the  fm, 
calls  “auxmod”  to  connect  the  fm  W175  and 
the  RF  channel  of  the  specified  VCO,  then 
returns. 

“AM175”  (VCO  number,  maximum  dB,  W175 
block  rate,  function  number) 

(396  bytes;  line  114) 

Sets  up  the  am  W175  to  give  an  am  waveform  as 
specified  by  the  passed  parameters.  This  calls 
“AMaux.” 

1 .  Checks  that  the  VCO  number  is  legal. 

2.  Checks  that  the  block  rate  is  legal  (see  Ap¬ 
pendix  H). 

3.  Checks  that  the  function  number  is  legal. 

4.  Calculates  the  W175  voltage  corresponding  to 
the  specified  maximum  dB  depth  (p5)  and 
checks  that  it  is  within  range. 

5.  Sets  up  U$  to  contain  the  specified  block  rate. 

6.  Modifies  U$  to  contain  the  voltage  amplitude 
and  offset  and  the  function  number,  and  to 
turn  on  the  50  ohm  output. 

7.  Sends  U$  to  the  am  WI75  to  set  the  am 
waveform,  calls  “AMaux”  to  connect  the  AM 
W175  to  the  RF  channel  of  the  specified  VCO, 
and  returns. 

"DC175”  (%  duty  cycle,  period,  WI75  number, 
VCO  numbers.  .  .) 

(550  bytes;  line  121) 

Sets  up  either  WI75  to  provide  a  simple  pulse 
waveform  to  the  RF  channels  of  the  specified  VCOs. 
Up  to  six  VCOs  may  be  specified  if  they  are  all  in 
different  RF  channels.  The  am  W 1 75  is  indicated  by  a 
W175  number  of  1  and  the  FM  W175  is  indicated  by  a 
2.  The  simple  pulse  waveform  (one  on/off  pulse  per 
period)  is  taken  from  the  WI75  square  wave  function 
block;  a  partial  block  is  used  to  get  the  specified  duty 
cycle.  The  period  in  milliseconds  is  used  to  set  the 
block  rate  in  hertz. 
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1 .  Sets  up  a  for/next  loop  (index  X)  to  check  the 
passed  VCO  numbers,  and  checks  that  the 
VCO  numbers  are  legal. 

2.  Calculates  the  rf  number  (pi  1)  of  each  VCO 
number  and  checks  that  RF  number  has  not 
already  been  used. 

3.  Sets  a  flag  (pl2-pl7)  to  indicate  that  the  RF 
number  has  been  used,  and  continues  the 
for/next  loop.  The  line  then  checks  if  the 
W175  number  is  legal. 

4.  Checks  if  the  %  duty  cycle  is  within  range. 

5.  Checks  if  the  period  is  too  low. 

Note:  The  fifth  line  checks  the  period  against  a  limit 
of  0.051  (ms),  corresponding  to  a  maximum 
rate  of  19.5  kHz,  the  full  block  limit.  Since  a 
partial  block  will  be  used  (unless  the  duty  cycle 
is  50%),  the  actual  limit  would  be  lower, 
depending  on  the  actual  block  size  and  hence 
the  duty  cycle.  The  limit  in  the  fifth  line  might 
be  replaced  by  an  expresion  that  allows  for  the 
actual  block  size,  which  would  be  somewhat 
more  complex.  The  limit  value  might  also  be 
replaced  by  a  simple  value  of  2e-3  for  the  5.1e- 
2,  to  reflect  the  500  kHz  response  limit  of  the 
pulse  circuits.  There  is  no  upper  limit  check 
since  it  is  felt  unlikely  that  any  real  test  will 
need  pulse  periods  greater  than  71  hours. 

6.  Calculates  the  start  and  stop  addresses  (pi 3 
and  pi 2,  respectively)  for  the  square  wave 
function  block  The  line  modifies  the  stop 
address  if  the  duty  cycle  is  less  than  or  equal  to 
50%. 

7.  Modifies  the  start  address  if  the  duty  cycle  is 
greater  than  50%. 

8.  Seta  U$  to  contain  the  start  and  stop  addresses, 
the  partial  block  indicator,  the  voltage  am¬ 
plitude  and  offset,  and  the  function  block 
number,  and  to  turn  off  the  50  ohm  output. 

9.  Modifies  U$  to  contain  the  block  rate 
corresponding  to  the  passed  period;  then 
conditionally  jumps  one  or  two  lines, 
depending  on  vhich  W175  was  specified  as  the 
pulse  source. 

10.  Sends  U$  to  the  AM  WI75,  then  jumps  two 
lines  to  the  twelfth  line. 

11.  Sends  U$  to  the  FM  W175. 

12.  Sets  up  a  for/ next  loop  (index  X)  that  calls 
“pulse”  to  connect  the  WI75  serving  as  the 
pulse  source  with  the  rf  channel  of  each 
passed  VCO. 

13.  Completes  the  for/ next  loop,  then  returns. 


“T/P”  (period,  VCO  numbers.  .  .) 

(266  bytes;  line  134) 

Sets  the  multiprogrammer  timer/pacer  card  as  a 
pulse  waveform  source  for  the  specified  VCOs.  Up  to 
six  VCOs  may  be  specified  if  they  lie  in  different  rf 
channels.  The  pulse  waveform  is  a  50%  duty  cycle 
square  wave.  The  timer/pacer  card  should  already  be 
in  its  recirculating  mode,  as  set  by  “initial”;  if  the 
user  has  changed  the  card  mode  it  is  up  to  the  user  to 
reverse  that  change. 

1.  Checks  that  the  period  is  legal. 

2.  Sends  the  period  to  the  multiprogrammer, 
putting  the  new  period  value  in  Z 1 13  ] . 

3.  Sets  up  a  for/next  loop  to  handle  the  checking 
and  setting  for  each  passed  VCO  number.  The 
loop  begins  by  checking  that  the  VCO  number 
is  legal. 

4.  Calculates  the  rf  number  of  the  VCO  being 
checked  (p9)  and  checks  that  the  rf  channel 
has  not  already  been  used. 

5.  Sets  an  RF  use  flag  (plO-pl 5),  then  calls 
“pulse”  to  connect  the  timer/pacer  card  to  the 
pulse  circuit  of  the  rf  channel  of  the  specified 
VCO.  The  loop  then  continues.  When  done, 
the  subroutine  returns. 

“special”  (bandjiumber,  rate^jjme  at  rale,  table 
length) 

(392  bytes;  line  139) 

Uses  the  controller  to  run  a  synchronous  pattern 
on  the  three  available  VCOs  in  a  band.  Both  tune 
centers  and  channel  function  control  words  can  be 
changed  at  each  step.  The  changed  values  are 
determined  by  the  user-provided  nextval  function 
“valspec”  (see  Appendix  P).  The  reat  ?r  should  see 
the  notes  on  this  subroutine  in  Appendix  K. 

1 .  Checks  tha:  the  band  number  is  legal. 

2.  Determines  the  channel  function  control  card 
slot  numbers  for  the  three  VCOs  in  the  band 
(p6,  p7,  and  p8,  in  order  of  increasing  VCO 
number)  and  the  slot  number  for  the  double 
word  tune  card  (i.e. ,  the  tune  card  on  which 
both  halves  control  a  VCO  within  the  specified 
band). 

3.  Checks  that  the  table  length  parameter  is  not 
less  than  zero. 

4.  Calculates  the  wait  on  each  output  step  (p9) 
and  checks  that  it  is  legal. 

5.  Calculates  the  number  of  output  steps  (p7), 
then  sets  up  a  for/next  loop  (index  X)  to 
handle  the  output.  The  loop  first  calls 
“valspec.” 
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6.  The  unchecked  and  unmanipulated  returns 
from  “valspec”  are  sent  directly  to  the 
multiprogrammer,  the  controller  waits  to 
establish  the  rate,  and  the  output  loop  con¬ 
tinues  until  done,  when  the  subroutine  returns. 

“err  stp” 

(286  bytes;  line  145) 

Handles  the  simulator  shutdown  and  program  stop 
directed  if  one  of  the  subroutine  blocks  finds  an  error 
during  a  check  (see  Appendix  F).  This  is  not  a  true 
subroutine  since  it  is  entered  by  a  branch  rather  than 
a  call,  and  it  has  no  return. 

1.  Sets  the  display  format  and  turns  off  the  50 
ohm  outputs  of  the  W 1 75s. 

2.  Sets  the  channel  function  control  cards  to  their 
“initial”  state:  pulse  and  biphase  carriers 
turned  off,  fill  oscillator  and  noise  generator 
set  to  full  attenuation,  and  video  turned  off. 
The  VCO  select  will  be  set  to  the  “B”  labeled 
VCO  in  this  process.  It  may  be  noted  that  this 
does  not  affect  the  Z  [  * ]  contents. 

3 .  Formats  the  error  code  contents  in  Z  into  three 
parts  (p21,  p22,  and  p23;  p24  is  a  holding 
variable).  See  Table  F-l  for  a  list  of  the 
subroutine  block  error  codes. 

4.  Writes  the  formatted  error  code  on  the 
HP9825’s  internal  printer. 

5.  Sets  up  an  endless  loop  that  beeps  and  flashes 
an  operator’s  notice  of  the  error. 

“shutoff” 

(236  bytes;  line  150) 

Handles  the  simulator  shutdown  and  program  halt 
directed  if  a  controller  error  is  encountered.  This 
must  be  enabled  (on  err  “shutoff”)  before  it  takes 
effect.  It  is  strongly  similar  to  “err  stp”,  differing 
only  in  the  error  information  printed. 

1.  Prints  a  notice  on  the  HP9825’s  internal 
printer,  turns  off  the  50  ohm  outputs  of  the 
W175s,  and  sets  the  display  format. 

2.  Turns  off  the  simulator  through  the  channel 
function  control  cards  (see  the  second  line  of 
“err  stp”). 

3.  Writes  the  controller’s  error  information  on 
the  HP9825’s  internal  printer. 

4.  Sets  up  an  endless  loop  that  beeps  and  flashes 
an  operator’s  notice  of  the  fault. 

“enter” 

(49C  bytes;  line  154) 

Converts  and  scales  an  input  alphanumeric  string 
to  a  numeric  form  that  is  returned  by  this  subroutine 


function  (see  Appendix  C).  The  syntax  checking  is 
minimal  but  should  work.  This  function  will 
sequentially  check  for  a  recognized  character 
anywhere  in  U$.  Note  that  this  means  the  operator 
cannot  combine  an  exponential  form  number  with  a 
character.  If  a  recognized  character  is  found,  the 
function  will  treat  all  of  the  string  up  to  that 
character  as  the  numerical  part  of  the  string.  Each 
tine  is  very  similar,  with  pi  as  the  scale  multiplier,  p2 
as  the  end  point  of  the  numeric  portion  of  U$,  and  p3 
as  a  character  position  holding  variable.  If  a 
character  is  recognized  by  a  line,  that  line  will  branch 
to  the  last  subroutine  function  line. 

1.  Initializes  the  multiplier  (pi)  and  end  pointer 
(p2),  then  checks  for  the  giga  prefix. 

2.  Checks  for  the  kilo  prefix. 

3.  Checks  for  the  micro  prefix. 

4.  Checks  for  the  mega  prefix. 

5 .  Checks  for  t  he  milli  prefix . 

Note:  As  mentioned  in  Appendix  K,  these  last  two 
lines  could  be  modified  to  eliminate  the  milli 
check  and  allow  either  an  upper-  or  a  lower¬ 
case  letter  M  to  indicate  the  mega  prefix. 

6.  Checks  for  a  dB  indicator. 

7.  Checks  for  a  Hz  indicator. 

8.  Checks  for  a  seconds  indicator. 

9.  Checks  for  the  exponent  sign  (if  found,  then 
the  entire  string  is  assumed  numeric). 

10.  "  label.  Finds  and  returns  the  scaled 
numeric  content  of  the  string. 


“inRFid” 

(224  bytes;  line  164) 

Prompts  an  operator  to  specify  a  VCO  by  the  rf 
channel  number  and  the  VCO  letter  label,  in¬ 
formation  available  to  an  operator  looking  at  the 
front  of  the  simulator  rack,  and  finds  the  VCO 
number  of  the  specified  VCO.  This  is  a  subroutine 
function. 

1.  Clears  out  old  U$  contents  and  specifies  a 
default  of  6B  (VCO  number  12),  then  prompts 
the  operator  to  make  an  entry.  The  cap 
function  is  used  so  that  the  operator  may  use 
upper-  or  lower-case  letters. 

2.  Checks  that  the  rf  channel  number  is  legal;  if 
it  is,  the  program  jumps  two  lines  to  the  fourth 
line. 

3.  Notifies  the  operator  that  the  entry  form  was 
bad,  indicates  the  correct  form,  and  then 
jumps  back  two  lines  to  the  first  line. 

4.  Checks  that  the  VCO  letter  label  is  legal;  if 
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not,  the  program  jumps  back  one  line  to  the 
third  line  (and  thence  back  to  the  first). 

5.  Calculates  and  returns  the  VCO  number  of  the 
specified  VCO. 


“load  Y$”  (VCO  numbers.  .  .) 

“load  X$”  (VCO  numbers,  video  number,  .  .  .) 
“load  W$”  (VCO  numbers.  .  .) 

(540  bytes;  line  169) 

These  subroutines  are  similar  enough  that  they  can 
be  described  together  as  a  general  “loadS”.  They  are 
used  to  update  the  controller  data  from  (ape.  They 
are  separate  so  that  only  the  data  affected  by  some 
program  change  need  be  updated.  Fill  oscillator  and 
FM  W175  data  are  updated  by  “loadYS”  and 
“loadWS”,  respectively:  the  only  difference  between 
the  two  is  the  string  involved  and  the  tape  files  used 
to  get  the  updated  data.  Noise  generator  data  are 
updated  by  “loadXS”,  which  includes  a  line  to 
identify  the  video  filter  number.  Up  to  six  VCOs  (or 
six  VCO/ video  number  pairs  for  “loadXS”)  may  be 
specified  in  one  call,  provided  the  VCOs  all  lie  in 
different  rf  channels. 


The  following  line-by-line  description  applies 

equally  well  to  either  "loadYS”  or  “ioadW$“;  the 

description  for  “loadXS”  that  then  follows  refers  to 

the  earlier  description. 

1 .  Sets  the  tape  track  number  to  track  1 ,  then  sets 
up  a  for/next  loop  (index  X)  to  handle  each 
passed  VCO. 

2.  Checks  that  the  VCO  number  is  legal. 

3.  Calculates  the  rf  channel  number  (pi 3)  and 
checks  that  that  channel  has  not  already  been 
used. 

4.  Sets  an  RF  use  flag  (p7-p!2),  then  transfers  the 
taped  data  through  V$  to  the  controller  data 
siring. 

The  line-by-line  description  for  “loadXS”: 

1 .  Same  as  first  line  above. 

2.  Same  as  second  line  above. 

3.  Checks  that  the  video  number  is  legal  and 
nonzero,  using  p20  as  a  holding  variable. 

4.  Same  as  third  line  above  (except  that  pl9  is 
used  to  hold  the  rf  number). 

5.  Same  as  fourth  line  above  (except  that  pi 3-pl 9 
are  used  as  the  rf  use  flags). 
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APPENDIX  Q 


SUBROUTINE  BLOCKS,  PROGRAM  LIST 


Note:  The  type  face  of  the  printer  used  for  the 
appended  program  listing  differs  from  that  of 
the  HP9825’s  internal  printer.  The  assign¬ 


ment  arrow  has  been  replaced  by  a  right  paren¬ 
thesis  and  the  power  arrow  by  a  caret. 

Note:  The  program  listing  is  that  of  October  1981. 
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"?“:red  72313, p3, p4; i t  bi  t.  <p  1  ,  p  ( 2+p2>  '  ;  imp  O 
ret 

"tval#":it  Ip2/ Ie9>p3) < val < Z*Epl , 1 . 53 > ; 2e3+p 1 3 Z : qto  "err  stp" 
tor  0=2  to  6;  i  t  p3< =val ( Z«Cp 1 . 9V-B. 90-4 3 > ; 03p4; 1 03 V 
next  0;it  0< 10; 2100+pl 3 Z ; qto  "err  stp" 

(9p4>p9)-93p4; (val < Z*[p 1 , p9-3, p93 ) 3p6 ) -val ( Z*Cp 1 . p4-3, p4 3 > >p5 
p5/ < (val  (Z*Cpl,p9-B,p9-43> 3p7)-val  ( Z* Cp 1 , p4-8, p4-4 3 >  >p8) >p5 
i  nt  (p5  (p3-p7)  +p6)  >W;  i  t  W<0  or  W>255;  2200+pl >  Z;  qto  "err  stp" 
ret 

"tset":stq  14;it  pl<0  or  pl>12  or  t  rc  (p  1  >  ;  le33  Z ;  qto  "err  stp" 

2+1 nt (  (pl-.5)  74)  3p3; -83p4; 255! p5; i t  int <plmod4/2+. 5) =1 s 0>p4; 652803p5 
cl  1  ’  t val#’  (pi ,p2) s ior (band ( Z C p3 1 , p5> , sht (W, p4>  >  3 Z Cp33 
wrt  723, "OS" ,p3,ZCp33, "T" sell  ’?'(4,l);ctq  14;ret 
"tnoise“sit  pl<0  or  pl>12  or  tre (pi > ;5e33Z;qto  "err  stp" 

(int (pl/2+.5) 3p5>  +4>pl0;  (2.5eB) 2 ' ( 1 +2i  nt ( <p 1  - 1) 76) -plmod2>  >pl 1 
it  p2=0 ; 7! p 1 3!p 1 4; qt o  "tnout" 

it  p3>=0  and  p3<6  and  not  tre (p3) ; p3>p6; jmp  3 
it  p3=5e6; 5! p6; jmp  2 

1 oq (p3) -2! p6; i t  p6<  1  or  p6>4  or  tre  <p6)  ;  5200+p  1  >  Z  ;  qto  "err  stp" 
p4>pl3;it  p0=3; 403p7; 1 . 5pl 1 3pl3; jmp  4 

it  p4=l  or  p4=2  or  p4=3j < 1 . 2+. 3 ( 40 (p4- 1 > >p7> 740) p 1 1 3 p 1 3j jmp  3 
it  p4<pll  or  p4>2pl 1 s 5300+pl > Z; qto  "err  stp" 

ell  ’ tset ’ (pi , p4> 1 0}p7( i t  p4>l . 33pl 1 1 40>p7j i t  p4>l . 66p 1 1 ; B03p7 
it  pl3-p2/2<pl 1  or  p 13+p2/2>2p 1 1 s 5100+p 1 3 Z j qto  "err  stp" 
p2-(p2*Xt53>p8>  3p9;73pl33pl4;it  p6=Ojp23pB 

it  p8> (val  ( Y*Cp5, 1 +p7, 5+p7  3  >*le63pll>; p2- (p 1 1 3p8>  3p9s  03 p 1 3» 1 3p 1 5 
it  p9> (val  (X*Cp5, l+p7,5+p73 ) *le63pl 1 >  jp2-(pl 13p9> 3p8i0>pl4; 1 Jpl6 
it  pl5  and  p  1  t>s  5400+p  1  3  Z ;  qto  “err  stp" 
it  plSjjmp  3 

tor  X  — 1  to  7; i f  val  ( Y*tp5, 5X  +  1 +p7 . 5X+5+p7 3 ) *  1 e6<p8| X-l 3p 1 3; 103 X 
next  X 

it  pl6  or  p6=0| jmp  3 

tor  X-l  to  7s i t  val <X*Cp5.5X+l+p7,5X+5+p73) *lefe<p9s X-13pl4s 103X 
next  X 

"tnout " 1 stq  14; band  < Z Cp 103 . 65024) 3 Z C p 1 03 

i  or  ( Z Cp  1 03 ,  i  or  <i  or  ( sht  (pi  3,  -b) ,  sht  (p  1 4,  -3)  )  .  p6)  )  3 Z  Cp  1 03 

wrt  723, "OS" ,pl0,ZCpl03,"T";cll  ’?’(4,l);cfq  14;ret 

"pulse"sit  pl<l  or  pl>12  or  tr c (p 1 ); 3e3> Z ; qto  "err  stp" 

it  p2<0  or  p2>7  or  t r c <p2) 1 3100+pl 3 Z 1 qto  "err  stp" 

stq  14s ior (sht (p2,-9> .band (ZCint (pi /2+. 5) +43p33 , 61 951 ) >  JZCp33 

wrt  723, "0S",p3, ZCp33. "T"scl 1  ’?’(4,l);ctq  14;ret 

"biph"sit  pl<l  or  pl>12  or  tre (pi > : 4e33 Z ; qto  "err  stp" 

it  p2<0  or  p2>7  or  tre (p2) » 4100+pl 3 Z 1 qto  "err  stp" 

stq  14; ior (sht  <p2, -12) . band ( Z C i nt (p 1 /2+. 5> +4>p33 , 36863 ) >3ZCp33 

wrt  723, "OS" ,p3,ZCp33, "T" ; cl  1  ' (4, 1 ) jetq  14;ret 

" aaxmod 1 t  pl<0  or  pl>12  or  tre (p 1 >; 6e33 Z 1 qto  "err  stp" 

it  p2<0  or  p2>3  or  tre (p2) ; 6100+p 1 3 Z; qto  "err  stp” 

stq  14;ior(band(ZC123, 1023) , ior (sht (int (pl/2+.5) ,-10) ,sht (p2. -13) > ) 3ZC123 
wrt  723, "OS, 12", ZC123, "T"scll  ' (4, l > ; wai t  1 

wrt  723, "OS, 12" .band (ZC 123.58367) 3ZC 123, "T";cl 1  *?'(4,l)|ctq  14;ret 

"AliauH";it  pl<0  or  pl>12  or  tr  c  (p  1  >;  1 70003  Z ;  qto  "err  stp" 

it  p2<0  or  p2>3  or  tre <p2> ; 17100+p 1 3 Z ; qto  "err  stp" 

stq  14; ior (band ( Z C 1 23 , 65472) . ior (int (pl/2+,5) ,sht (p2. -3) ) ) 3 Z C 1 2 3 

wrt  723, "OS. 12", ZC 123, ”T";cl 1  ’ ?' (4, 1 ) 1 wai t  1 

wrt  723, "OS, 12", band ( Z C 1 2 3 , 65528) 3ZC123, "T";cll  * (4, 1 ) ictq  14»ret 
"ampset.  "lit  pl<l  or  pl>12  or  t  rc  (p  1 )  ;  7e33  Z ;  qto  "err  stp" 
it  (p23p4)<0  or  p4>81 1 7100+p 1 3 Z| qto  "err  stp" 
it  p4“81 1 703p4; 153p3; jmp  3 
it  p4=80; 703p4; 143p3; jmp  2 

p4modl03p33p5; it  p3>=8; 123p3; i t  p5=9t 133p3 
stq  1 4; band ( Z C 1 1 3 , 64512) 3  Z C 1 1 3 

ior (int (pl/2+,5) -1 , ior (sht  < (p4-p4modl0> / 10, -7) , sht  <p3, -3) ) >  3 ZC 1 1 3 
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62 

(ji 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 
87 
8E 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 

106 

107 

108 
109 
HOi 
111 
112 
113 
U4i 
115 
116: 
117 
1  18 

119 

120 
121 
122 


wrt  723 ,  "  OS  ,ll",ZC113,"T";cll  ’?’<4,l);cfg  14;ret 
"  AMown  ”  i  i  f  pl<l  or  pl>12  or  f  r  c  <  pi )  ;  Be33  Z ;  qto  "err  stp" 

!f  ( i nt ( Ie3/p2) -XC43 3p4) <0  or  p4>32767; 8100+pl > Z ; gto  "err  stp" 

99+int <pl/2+.5> 3p5;cl 1  ' AMaux ' <p 1 , 2> ; f or  X  =  1  to  p3;cll  ’AMval’(pl) 

it  LKO  or  U>10X [111; 8200+p 1 3  Z ; qt o  "err  stp" 

wrt  723, "0S",p5,U, "T";wait  p4;cll  ' ?' < 4. 1 ) s nex t  X 

wrt  723, "0S",p5, Z tp5-853 , “ T" ; cl  1  ’?’<4,l)jret 

"setVCO"  I  sf  g  14;if  pl<0  or  pl>12  or  f  rc  (pi  >  ;  le4>  Z;  qto  "err  stp" 
ior (band (ZCint (pl/2+.5) +4)p23 , 32767) , shf (plmod2, -15) ) 3ZCp23 
wrt  723,  "OS" ,p2,  Zf  p23 ,  "T" ; cl  1  ' ?'  (4,  1 ) ; cf q  14;ret 

"initial  "sclr  7;tr):  ljldf  91,U*;prt  U*:wait  3500;wrt.  723,  "WF,  13.  2,  1 ,  T" 

wait  350; i na  Z;for  X=2  to  12;wrt  723, "SF“ . X . 2. 1 , 1 , "T" ; wai t  100 

newt  X ;  'or  X  =  1  to6«wrt  723, “OS" , X+4. 327603 Z t X+4 3 , "T" ; cl  1  ’?’<4,1> 

wrt  723, "OB", X+4, 15, 1 , "T, WA, ,5T,0B", X+4, 15,0, "T" 

wrt  723, "OS, 12", ior (shf (X, -10) , X) , "T";cl 1  ’?’<4,1> 

wrt  723, "OS, 11", ior (1008, X-l) , "T";cll  ' <4, 1 ) ; next  X 

wrt  723, "OS, 12,0,T";ret 

"stepmod":if  pl<l  or  pl>12  or  f rc (p 1 ); 1 1000) Z ; qto  "err  stp" 

2+int ( <pl-.S> /4> 3p4 

ZCp433p6;-83p5; 2553 p3; it  int (p lrood4/2+ . 5) =1 ; 01p5; 65280) p 3 
stg  14;tor  X=1  to  p2;cll  ’ step val ’ (p 1 > 
it  U<0  or  (J>255  or  trc  (U)  ;  1 1  lOO+pl  >  Z ;  gto  "err  stp" 
wrt  723, "OS" . p4, ior (shf (U, p5> , band (p6, p3) ) >p6, "T" 

ell  ’ stepwt ’  (p 1 > ; int (U— X C2) > )U; i t  U<0  or  U >32767 1 1 1200+p 1 ) Z ; gto  "err  stp" 
wait  U;cll  ’ ?’ (4, 1 ) ; next  X 

wrt  723 , " OS ",p4,ZCp41, "T";cll  ' ?' ( 4 , 1 > ; ctg  14«ret 
"ownswp" lit  pl<l  or  pl>12  or  t r c (p 1 > ; 9e3> Z ; qto  "err  stp" 

2-*-int(  <pl--5)  /4)  )pl0;-8)pl4;255>pl2;  it  int  (plmod4/2+.  5)  =1  ;0>pl4;65280)pl 2 

band (pl2,ZCpl0))>pl5;cll  ’fval#’ (pl,p2);W)p7 

ell  ’fval#’  (pl,p3> jit  ( W)p8) <p7; p8)p 1 1 ; p7)p8; pi  1 >p7 

if  < (Ie3(p3-p2> /p4)pll) / (p8-p7>p6) -X C3 3 >p 1 3> >32767; 91 00) Z ; gto  "err  stp" 

1  >t"'  I  i  f  pl3>=0;jmp  2 

0>p.3| i nt (p6*X [33/pl 1 ) >p9; i f  p9< 1  or  p9 >p6; 9200+p 1 > Z ; gto  "err  stp" 
f  ir  Y=2  to  p5+l;for  X=p7  to  p8  bv  p9 

wrt  723, "OS",plO, ior (shf (X,pl4) ,pl5> , "T";wait  pl3;cll  * ?* (4, 1 ) ; next  X 
for  X— p8  to  p7  by  -p9;wrt  723, "OS" , p 10, i or ( shf ( X , p 1 4 ) , p 15) , "T" 
wait  pl3;cll  ’ ?’ (4, 1 > ; next  X;next  Y;wrt  723, “OS" , p 10, Z t p 10) , "T " 
ell  ’?'(4,l))cfg  14;ret 

"swpl75"iif  pl<l  or  pl>12  or  f rc <p 1 ); 1 40003 Z ; qto  "err  stp" 
i nt (pi /2+. 5) 3p6; i f  p4>1.95e4  or  p4<0; 1 4 100+p 1 3 Z ; gto  "err  stp" 
if  (p5<0  or  p5>ll)  and  <p5<14  or  p5>21 ) ; 1 4200+p 1 3 Z ; gto  "err  stp" 
l+2int  < (pl-1 ) /6' -plmod2)p7;7)pl2 

(2. 5e8)  2'Np73p  10;  03p  1 1 ;  i  f  p2>l .  33p  1 0;  403p  1 1 ;  i  f  p2>l .  66p  10|  B0)p  1 1 

if  p2+p3/2>2pl0  or  p2-p3/2<p 10 ; 1 4300+p 1 3 Z ; gto  "err  stp" 

for  X=1  to  7; i f  ( val ( W*Cp6, 5X+ 1+pl 1 , 5X+5+p i 1 3 > )p 14) >»p3/ le6; X)p 12| 1 0) X 

next  X;if  X<9; val (W*Cp6 , 5p 1 2+ 1 +p 1 1 , 5p 1 2+5+p 1 1 3 ) 3p 1 4 

val (M*Cp6, 5p 1 2— 4+p 1 1 , 5p 1 2+p 113) 3pl3 

(XC  133/  (pl4-pl3>  3pl3)  (p3/ le6)  +  ( XC  1 23 t-p  12*X  C  1 33  ) -p  1 3p  1 43p8 
if  p8<le-3  or  p8>XC 103 ; 14400+p 1 3 Z ; gto  "err  stp" 

"  " 3 U* ;  f  1 1  1 ;  "F"!<str  (p4 )  3U#;  "E" 3U*C6, 63 ;  f  xd  2 

U*3<" A"l<str  <pB>  &"C“!<str  (p5)  !<"D0P  1 1  "3U* 

ell  ’ f set ’ <pl , p2) ; wrt  701,U*jcll  ’ auxmod ’ <p 1 , 3) ; r et 

"AM175"tif  pl<l  or  pl>12  or  f rc (p 1 ) I  1 . 8e4) Z ; gto  "err  stp" 

if  p3<0  or  p3>1.95e4; 18100+p 1 3 Z; gto  "err  stp" 

if  (p4<0  or  p4>ll>  and  (p4<14  or  p4>21 ) ; 18200+p 1 3 Z ; qto  "err  stp" 
if  <p2/XC 1 1 33p5> < le-3  or  p5>X t 1 4 3 ; 1 B300+p 1 3 Z ; gt o  "err  stp" 

""3U*;flt  1 ;  "F”S<str  (p3>  )U*;  "E"  3U4C6, 63 ;  f  xd  2 

U*!<"A"S<str  <p5>  !<"D"fcstr  (p5/2>  )U*;  f  xd  0;  U**<"C"«<str  (p4)  *<"P1 1  "  3U* 
wrt  702, U*| c 1 1  ’ AMaux ’ (pi, 3); ret 

"DC175" ■ for  X-4  to  pO;if  pX<l  or  pX>12  or  f rc (pX ) ; 1 5000+X 3 Z ; gto  "err  stp" 
i nt (pX/2+.5)3pll|if  p ( 1 1+p 1 1 ) ; 1 51003 Z | gto  "err  stp" 
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123s  l)p ( 1 1+pl 1 > snext  X ji f  p3#l  and  p3«2j 1 52003 Z s qto  "err  stp" 

124s  if  pl<0  or  p 1 >100: 15300 Z \ qto  "err  stp" 

125s  l f  p2<5. le-2j 15400! Z$ qto  "err  stp" 

126s  0 > p 1 3 s  255 }  p  1 2  s  i  f  p 1 050: 255-1 nt (2. 54 (50-pl ) ) >pl2( jmp  2 
127s  i nt  <2. 54  <p 1 -50 > ) }p  1 3 

128s  f  xd  Os  "">U*s  "W"S<str  (p  1  2)  S, "  V"S<str  (pl3)  8i"Ul  A2D1C2P0"  >U« 

129s  tit  1  :U*&"F"?<str  ( Ie3/p2>  «<"  I  "  }U*s  cap  <LI*>  }U*s  imp  p3 
130s  wrt  702,U#sjmp  2 
131s  wrt  701. U* 

132s  tor  X=4  to  pOscll  ’ pul se ’ <p X , p3+2) 

133s  next  Xsret 

134s  "T/P"sit  pl<2e-3  or  p 1 >le7 ; 1 6000} Z s qt o  "err  stp" 

135s  wrt  723, "OS, 13",pl/2, "T";cl 1  ' <4, 1 ) j pi > Z C 131 

136s  tor  X=2  to  pO;it  pX'l  or  pX>12  or  t r c (pX ) ; 16100+X } Z s qto  "err  stp" 

137s  i nt  <pX/2+.  5)  >p9;  i  t  p (9+p9) s 16200} Z s gto  "err  stp" 

138s  1 }p (9+p9) s cl  1  ’ pul se’  <pX , 5) s nex t  Xsret 

139s  "special"sit  pl>3  or  pl<0  or  t rc <pl ) : 1 2000} Z s ato  "err  stp" 

140s  <<8}p6)+l}p7)+l}p8s41p5;it  pl<2s23p5i ((53p6>+l}p7>+l}p9 

141s  it  p4<0s 12100+p6} Z ; qto  "err  stp" 

142s  int ( le3/p2-XC 1 ]) >p6s if  p6<0  or  p6>32767j 1 2200} Z : qto  "err  stp" 

143s  int (p2p3) }p7s tor  X=0  to  2p7  by  2;cll  ’ val spec ’ (p4> 

144*  wrt  723, "OP"  )5,U,3,W,p6,Y,p7,Z,p8,V. “T"; wai t  p6|Cll  ' ?’ (2, 1 ) I  next  Xsret 
145s  "err  stp"stxd  Oswrt  701 . "POI " s wrt  702, "POI" 

146s  wrt  723, "OP, 5, 32760. 6, 32760, 7. 32760, 8, 32760, 9. 32760, 10, 32760, T" 

147s  (int  <Z/le2> }p24)-10(int  <Z/le3) }p2! ) 3p22s  Z-100p24}p23 

148:  tmt  1,  "faults  " ,  1 2. 0, 2x  ,  1 1 . 0,  >; ,  1 2. 0,  2/ s  wrt  16.  1 ,  p21 ,  p22,  p23 

149s  dsp  "*  error  ",Z,"  *" s beep s wai t  1250sdsp  ""swait  99s jmp  0 

150s  "shutot t " s prt  "stopped  /  error"swrt  701 , "POI " s wrt  702, "POI " q f xd  0 

151 s  wrt  723, "OP, 5, 32760,6, 32760, 7, 32760. 8. 32760, 9, 32760, 10, 32760, T" 

152s  tmt  1, "error  " , c , f 3. 0, / , "1 i ne#" , t 3. 0, 2/1 wr t  16. 1 , char (rom) , ern, er 1 
153s  dsp  "*  shutdown  *“staeepswait  1250;dsp  ""swait  99s jmp  0 
154s  "enter " s 1 !p 1 s 32}p2s i t  pos (cap <U*) , "B" > >p3s p3- 1 }p2; le9}p 1 s qto 
155s  it  pos (cap (US) , "K" ) >p3s  p3-l >p2l le3}p 1 ; gto  "}" 

156:  it  pos (cap <U*> , "U“ ) }p3; p3-l }p2» le-6}p 1 s qto  "}" 

157:  it  pos(U*. "M")!p3sp3-l}p2s le6>plsgto  "}" 

158s  it  pos (U*, "m" ) }p3s p3-l }p2; le-6}pl 5 gto  "}" 

159s  it  pos (cap (U*> , "D" ) }p3s p3-l }p2s 1 Tpl i gto  "}" 

160s  it  pos  (cap  (IJ*> ,  "H” )  }p3s  p3-l  }p25  1  }p  1 8  qto  "}" 

161:  it  pos (cap (U< ) , "S" ) }p3s p3- 1 }p2s 1 }p 1 s gto  "}“ 

162:  it  pos (U*, "e" ) s 32}p2s 1 ’ P 1 : qto 
163:  " } " s  ret  val  (U*C 1 , P2I > *pl 

164:  "  i  nRF  id":  "  6b  "  }  IJ*  s  en  t  "RF#(l-6).  VCO-  ( A,  ED  "  ,  U*C  1 . 2]  ;  cap  ( U*>  }U* 

165:  it  (num (U*C 1 , 1 } ) }pl > >48  and  pl<55| jmp  2 

166s  dsp  "bad  tormj  reenter  (e.q.;  ’6a’ ) "swait  2500s jmp  “2 

167 s  it  (num(U*C2,2I ) }pl ) #65  and  pl#66s jmp  -1 

168:  ret  2val <U*C 1 , 1 ] ) +p 1 -66 

169:  "loadY*":trk  l:tor  X=1  to  pO 

170:  it  pX<l  or  pX>12  or  trc (pX ) : 1 3000} Z; gto  "err  stp" 

171s  it  p ( ( i nt (pX /2+. 5) }p 1 3> +6) s 1 3100+pX } Z s gto  "err  stp" 

172:  pl3>p(pl3+6> sldt  pX+6 . V*s V*} Y*t p 1 3} ; nex t  Xsret 

173:  "loadX*"strk  lstor  X=1  to  2p0-l  by  2 

174:  it  pX<l  or  pX>12  or  t rc (pX ); 1 3200} Z s gto  "err  stp" 

175s  if  (p  (X+l  >  >p20Xl  or  p20>5  or  f  rc  (p20)  ;  1 3300+p  X  }  Z  s  qt  o  "err  stp" 

176:  if  p ( ( i nt (pX/2+. 5) 3 p 19) +12) s 13400+pX3Z s qto  "err  stp" 

177:  pl9}p (pl9+12) s ldf  5pX+p20+13, V*s V*} X*Cp 19} : nex t  Xsret 
178s  "1 oadW*" s trk  lstor  X=1  to  pO 

179s  if  pX<l  or  pX>12  or  f rc (pX ) s 13500} 7s qto  "err  stp" 

1801  if  p ( ( i nt (pX/2+. 5) }pl 3) +6) ; 1 3600+pX3 Zs qto  "err  stp" 

181s  p 1 3}p (p 1 3+6) sldt  pX+78, V*s V*>W*Cp 13} s next  Xsret 
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